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AGENDA 


Monday,  September  27,  2004 

• 8:30-9:00  AM:  Meeting  of  Plug-fest  participants.  This  session  is  open  only  to  Plug-fest  participants. 

• 9:00  AM  - 12:15  PM:  Plug-fest  integration  tests.  This  session  is  open  only  to  Plug-fest  participants. 

• 10:30  AM:  Morning  coffee  break 

• 12:15-1:15  PM:  Lunch  at  NIST  cafeteria  (not  included  in  registration  fee) 

• 1:1 5-5:00  PM:  Plug-fest  integration  tests.  This  session  is  open  only  to  Plug-fest  participants. 

• 12:30-1:15  PM:  Tutorial  participants  registration 

• 1:15-5:00  PM:  IEEE  1588  Tutorial:  John  C.  Eidson,  Agilent  Technologies 

• 3:00  PM:  Afternoon  refreshment  break 


Tuesday,  September  28,  2004 

• 8:00  AM:  Bus  leaves  conference  hotel  for  NIST  facility 

• 8:30-9:00  AM:  Continental  breakfast,  meet  other  attendees,  pick  up  conference  badges  and  material.  (Allow  30 
minutes  from  arrival  at  the  main  gate  due  to  security  and  parking) 

• 9:00-9:15  AM:  Conference  Opening 

Moderator:  Kang  Lee,  NIST 

o Welcome  from  Dr.  Hratch  G.  Semerjian  - Acting  Director  of  NIST 
o Administrative  details 


• 9:15  AM  to  10:30  AM:  Technical  Paper  Presentations  Session  I 

Moderator:  Oyvind  Holmeide,  OnTime  Networks  AS 


o 9:15-9:40  AM:  A Flexible  and  Scalable  Network  Simulation  Environment  for  Clock  Sviichronization: 
Roland  Hoeller,  Georg  Gaderer,  Hannes  Muhr,  Nikolaus  Kero,  Vienna  University  of  Technology  and 
Oregano  Systems 

o 9:40-10:05  AM:  Implementation  Design  and  Performance  Issues:  Hans  Weibel,  Dominic  Bechaz, 
Zurich  University  of  Applied  Science 

o 10:05-10:30  AM:  Industrial  Automation  Requires  Synchronization  of  Line  Topology:  Antonius 
Boiler,  Siemens 

• 10:30  - 10:50  AM:  Morning  coffee  break 


• 10:50  AM- 12:30  PM:  Technical  Paper  Presentations  Session  II 

Moderator:  John  C.  Eidson,  Agilent  Technologies 


o 1 0:50- 11:15  AM:  IEEE  1588  Ethernet  Switch  Transparency:  Sven  Nylund,  Oyvind  Holmeide,  OnTime 
Networks  AS 

o 1 1:15-1 1:40  AM:  Bridging  Networks  with  PTP:  Karl  Weber,  Siemens,  JUrgen  Jaspemeite.  Phoenix 
Contact  GmbH 

o 1 1 :40  AM-12:05  PM:  Implementation  Results  of  an  IEEE  1588  Boundary  Clock:  Dirk  S.  Mohl, 
Hirschmann  Electronics 

o 12:05-12:30  PM:  PHYs  and  Symmetrical  Propagation  Delay:  Thomas  Muller,  Zurich  University  of 
Applied  Science,  Alexander  Ockert,  Hilscher,  Hans  Weibel,  Zurich  University  of  Applied  Science 


• 12:30-1 :30  PM:  Lunch  at  NIST  cafeteria 
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• 1:30-3:10  PM:  Standards  And  Business  Related  Activities 

Moderator:  Kang  Lee,  NIST 

o 1:30-1:50  PM:  Report  of  the  User  Requirements  Task  Group:  Silvana  Rodrigues,  Zarlink 
Semicondiietor,  Steve  Zuponeic,  Roekwell  Automation 

o 1:50-2: 10  PM:  Report  of  the  Technical  Extensions  Task  Croup:  John  C.  Eidson.  Agilent  Teehnolouies 

o 2:1 0-2:30  PM:  Report  of  the  Conformance  Task  Group:  Oyvind  Holmeide,  OnTime  Networks  AS 
o 2:30-2:50  PM:  Presentation  of  Draft  PAR:  John  C.  Eidson,  Agilent  Teehnologies 
o 2:50-3:10  PM:  Proposal  for  IEEE  1588  Trade  Association:  John  C.  Eidson,  Agilent  Technologies 

• 3:10-3:30  PM:  Plug-fest  Introduction:  Objectives,  Participants,  and  Results 

Moderator:  Anatoly  Moldovansky,  Rockwell  Automation 

• 3:30-3:45  PM:  Afternoon  refreshment  break 

• 3:30-5:00  PM:  Attendees  view  and  discuss  Plug-fest  in  Lecture  Room  B 

• 5:15  PM:  Bus  leaves  NIST  for  conference  hotel 

• 6:30-9:00  PM:  Conference  Reception  And  Dinner 

Bus  leave  conference  hotel  restaurant 

o 6:45-  7:15  PM:  No-host  cash  bar 

o 7: 15  PM:  Conference  Dinner 

o 9:00  PM:  Bus  leave  restaurant  for  conference  hotel 

Wednesday,  September  29,  2004 

• 8:00  AM:  Bus  leaves  conference  hotel  for  NIST  facility 

• 8:30-9:00  AM:  Continental  breakfast 

• 9:00  AM  to  10:15  AM:  Technical  Paper  Presentations  Session  111 

Moderator:  John  D.  McKay,  Progeny  Systems 

o 9:00-9:25  AM:  IEEE  1588  over  IEEE  802,1 1 b for  Synchronization  of  Wireless  Local  Area  Network 
Nodes:  Afshaneh  Pakdaman,  Todor  Cooklev,  San  Francisco  State  University;  John  Eidson,  Agilent 
Technologies 

o 9:25-9:50  AM:  High  Accuracy  Clock  Synchronization  Using  IEEE  1588:  Pritam  Baruah,  Pruthvi 
Chaudhari,  Paul  Corredoura,  John  C.  Eidson,  Andrew  Fernandez,  Bruce  Elamilton,  John  Stratton,  Dieter 
Vook,  Agilent  Technologies 

o 9:50-10: 15  AM:  Primary  Timing  Reference  Sources  for  IEEE-1588  Systems:  Paul  Myers,  Spectracom 

• 10:15  - 10:35  AM:  Morning  coffee  break 

• 10:35  AM  to  12:15  PM:  Technical  Paper  Presentations  Session  IV 

Moderator:  Anatoly  Moldovansky,  Rockwell  Automation 

o 10:35-1 1:00  AM:  DeviceNet  Adaptation  of  IEEE  1588:  Ron  Holl,  Dave  VanGompel:  Rockwell 
Automation 

o 1 1 :00-l  1 :25  AM:  Hardware  Assisted  IEEE1588  Implementation  in  a Next  Generation  Intel  Network 
Processor:  Puneet  Sharma,  Intel  Corporation 

o 1 1 :25-l  1 :50  AM:  Interfacing  Mil  Standard  f^quipment  to  an  IEEE  1588  Enabled  Ethernet  Network: 
John  D.  MacKay,  Progeny  Systems 

o 1 1 :50  AM-12: 15  PM:  Automatic  Test  Systems  using  LAN-based  Synthetic  Instruments  and  the  Role 
of  IEEE  1588:  John  Stratton,  John  Swanstrom,  Agilent  Technologies 
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12:15-1:15  PM:  Lunch  at  NIST  cafeteria 


1:15  to  2:05  PM:  Technical  Paper  Presentations  Session  V 

Moderator:  John  C.  Eidson,  Agilent  Technologies 

o 1:1 5-1 :40  PM:  IEEE  1588  in  Telecommunication  Apnlications:  Dave  Tonks,  Semtech 
o 1 :40-2:05  PM:  IEEE  1588  Telecom  llse  Cases  and  L2  Ethernet  Multicast:  Glenn  Algie,  Nortel 
Networks 

2:05-3:50  PM:  Discussion  Session 

Moderator:  Kang  Lee,  NIST  & John  Eidson,  Agilent  Technologies 

o 2:05-2:30  PM:  Discussion  & Attendee  Feedback  on  IEEE  1588  PAR 
o 2:30-3:00  PM:  Discussion  & Attendee  Feedback  on  IEEE  1588  Trade  Association 

3:00-3:20  PM:  Afternoon  refreshment  break  & networking 

o 3:20-3:50  PM:  Open  Discussion  on  Other  Issues 

3:50-4:00  PM:  Closing  Comments 
o Kang  Lee  & John  Eidson 

4:00  PM:  Conference  adjournment 

4:30  PM:  Bus  leaves  NIST  for  conference  hotel 


EXECUTIVE  SUMMARY  FROM  THE  CONFERENCE  CQ-CHAIRS 


The  conference  was  hosted  by  NIST  on  September  27-29,  2004  and  was  cosponsored  by  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  Instrumentation  and  Measurement  Society.  Acting  Director  of  the  National  Institute  of 
Standards  and  Technology  (NIST),  Dr.  Hratch  Semerjian,  opened  the  conference  with  a warm  welcome.  Dr.  Semerjian 
spoke  of  the  importance  of  standards  on  components  and  system  interoperability  and  his  assertion  of  interoperability’s 
role  in  the  expansion  of  the  PC  market  to  its  grand  scale  today.  Dr.  Semerjian  described  how  standards  are  basic  to  the 
culture  of  NIST.  Pursuing  device  and  system  interoperability  based  on  standards  is  one  of  NIST’s  goals.  More  than 
seventy  attendees  participated  in  the  conference,  coming  from  diverse  areas  such  as  instrumentation  and  measurement, 
industrial  automation,  aerospace,  power  generation,  semiconductor  manufacturing,  and  telecommunication. 

The  three-day  event  began  with  a tutorial  on  the  IEEE  1588  standard.  The  tutorial  was  unexpectedly  well  attended  by 
more  than  sixty  percent  of  the  attendees.  The  main  conference  started  on  the  second  day.  The  interoperability  of 
components  and  devices  was  demonstrated  by  seven  companies  and  a university  in  an  afternoon  session  informally 
dubbed  the  “Plug-fest.”  The  devices  were  built  to  IEEE  1588  specifications,  and  showed  that  they  could  be  synchronized 
to  a master  clock  to  sub-microsecond  accuracy.  The  interoperability  demo  was  led  by  Anatoly  Moldovansky  of 
Rockwell  Automation,  with  participation  from  Agilent  Technologies,  Hirschmann  Electronics,  OnTimc  Networks  AS, 
Rockwell  Automation,  Semtech  Corp,  Siemens,  and  Zurich  University  of  Applied  Sciences. 

Participants  were  impressed  with  the  smoothness  and  outcome  of  the  interoperability  demonstrations.  Some  components 
and  systems  were  able  to  achieve  clock  synchronization  to  within  +/-  40  nanoseconds  based  on  a master  clock  signal 
from  a global  positioning  system  (GPS)  antenna  located  on  the  lawn  outside  the  conference  facility.  This  illustrated  the 
effectiveness  of  the  1588  standard  and  the  ease  with  which  devices  can  be  built  to  its  specifications. 

The  technical  sessions  covered  subjects  such  as;  primary  timing  reference  sources  for  IEEE  1588  systems;  high  accuracy 
clock  synchronization  down  to  a nanosecond  for  precision  measurements;  network  simulation  environment  for  clock 
synchronization;  device  and  microchip  requirements;  and  adaptation,  implementation,  and  application  of  IEEE  1588  in 
industrial  automation,  military,  and  telecommunications.  A presentation  by  a graduate  student  on  the  application  of  IEEE 
1588  for  the  synchronization  of  wireless  local  area  network  nodes  based  on  802.1  lb  created  quite  a discussion.  The  field 
of  wireless  communications  is  of  great  interest  to  the  attendees,  who  expressed  a wish  to  see  more  detailed  results  in  this 
area  at  the  next  conference. 

As  a result  of  the  2003  IEEE  1588  Workshop,  three  task  groups  were  formed  to  address  the  issues  of  user  requirements, 
technical  extensions,  and  conformance  of  the  IEEE  1588  Standard.  The  results  of  these  three  task  groups  were  presented 
at  the  conference.  These  results  were  reflected  in  the  presentation  of  a potential  draft  project  authorization  request  (PAR) 
to  IEEE  and  the  possibility  of  forming  an  IEEE  1588  user  group  or  trade  association.  An  open  forum  was  held  on  the  last 
day  of  the  conference  to  further  discuss  the  issues  of  creating  a PAR  to  revise  the  IEEE  Std  1588-2002  Standard  and  the 
formation  of  a user  or  trade  group  to  promote  the  standard  and  facilitate  interoperability  tests,  and  of  enhancing  the 
standard  to  expand  its  coverage  from  the  instrumentation  and  measurement  to  other  industries  such  as  industrial 
automation  and  telecommunications. 

Based  on  the  feedbacks  of  the  attendees,  there  was  overwhelming  consensus  to  reopen  the  IEEE  1588  standard  to 
include: 

1.  Resolution  of  known  errors, 

2.  Conformance  enhancements, 

3.  Enhancements  for  increased  resolution  and  accuracy, 

4.  Improvements  to  system  management  capability, 

5.  Mapping  to  DeviceNet, 

6.  Modifications  for  variable  Ethernet  headers  (Annex  D), 

7.  Prevention  of  error  accumulation  in  cascaded  topologies, 

8.  Mapping  to  Ethernet  layer-2  small  frame,  shorter  sync  interval, 

9.  Extensions  to  enable  implementation  of  redundant  systems,  and 

10.  Improvements  to  extension  mechanism. 

If  the  standard  is  reopened  some  attendees  suggested  that  the  following  additional  items  be  considered  as  part  of  the 
scope; 
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■ Alignment  of  IEEE  1588  and  NTP  stratum, 

■ Clock  ID  ( identification)  alignment  with  telecom  T 1 . 1 0 1 G.8 1 2, 

■ Security  considerations-  currently  it  is  possible  to  take  over  the  GR  Role,  e.g.  with  preferred  master”  or  to 
manipulate  sync  packets,  security  IPv6  should  be  considered  for  backward  compatibility,  and  there  is  a need  to 
scope  the  problem  and  begin  to  get  around  it, 

■ Internet  protocol  version  6 (IPv6)  Authentication  - any  IPv6  issues  beyond  Ethernet  header  size, 

■ Authentification  for  network  security,  IPv6  is  essential  or  we  will  development  a proprietary  protocol  version  by 
necessity,  or  laycr-2  mapping, 

■ Backward  compatibility  with  current  standard  as  its  defined  today, 

■ IEEE  145 1 TEDS  (transducer  electronic  data  sheets)-like  information  on  clock  parameters.  Better  ID  of  stratum 
and  source, 

■ Main  point  is  authentication  security.  Other  protocols  do  this  at  layer-3.  However,  authentification  signature  is 
large  and  it  grows  over  time.  Further,  modification  of  packets  violates  authentication  signatures  or  they  need  to 
be  recalculated.  At  layer-3  IEEE  1588  should  not  do  its  own  security.  This  is  redundant  and  risky. 

■ Metadata  fonnat  to  allow  description  of  oscillator  and  time  source-ups  receiver,  vendor  extensions  for 
management  information  (MIB)  for  the  simple  network  management  protocol  (SNMP),  vendor  extensions  for 
metadata, 

■ Shouter  frames  and  variable  sync  internal  with  unicort  option  will  be  vital  to  wireless  sensor  nets, 

■ Best  master  group, 

■ Some  goals  may  be  harder  to  achieve  than  others.  Consider  fonnulating  more  than  one  PAR, 

■ Inclusion  of  sync  or  management  messages  that  permit  a grand  master  to  discover  the  time  error  of  each  slave. 

A message  that  can  be  decoded  to  produce  a hardware  interrupt  to  allow  a MC  (master  clock)  in  a computer 
without  a real-time  OS  (operating  system)  to  execute  an  emergency  operation  in  real  time. 

■ Mapping  to  the  control  area  network  (CAN)  open,  and 

■ SNMP  as  a requirement  for  system  management. 

Conference  Proceedings 

The  proceedings  for  the  conference  will  be  published  as  a NISTIR  (internal  report)  before  distribution.  They  will  be 

posted  in  the  IEEE  1588  website  at  http:/7ieeel  588.nist.gov  as  soon  as  it  is  approved  for  publication  by  NIST. 

Future  Workshop 

There  was  brief  discussion  on  the  plan  for  a future  IEEE  1588  conference.  Most  attendees  wanted  to  have  another  one. 

Location  will  be  either  at  NIST  or  in  Europe,  which  is  to  be  determined.  More  detailed  plans  for  the  next  workshop  will 

be  presented  in  the  spring  of  2005. 
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Company 

Ron  Holl, 

Dave  VanGompel 

Rockwell 

Automation 

DeviceNet  Adaptation  of  IEEE-1588 

DeviceNet  is  an  extremely  popular  device  level  industrial  network  and  is  ideal 
for  many  applications  requiring  synchronized  time,  yet  there  is  no  current 
mechanism  to  accomplish  this.  This  paper  describes  how  DeviceNet  will 
provide  this  function  by  adapting  it  to  IEEE- 1588  as  a standardized  PTP 
network  technology.  The  adaptation  includes  selection  of  a message  timestamp 
point,  specification  of  the  UUID,  definition  of  both  the  PTP  message  format  and 
PTP  addressing  on  the  subnet,  and  integration  into  the  DeviceNet  architecture. 

Roland  Hoeller, 

Georg  Gaderer, 

Hannes  Muhr; 

Vienna 
University  of 
Technology 

A Flexible  and  Scalable  Network  Simulation  Environment 
for  Clock  Synchronization 

Nikolaus  Kero 

Oregano 

Systems 

The  problem  of  synchronization  of  clocks  in  distributed  systems  has  received 
much  scientific  attention  throughout  the  last  decades.  A variety  of  algorithms 
has  been  published  and  issues  like  fault  tolerance  or  achievable  accuracy  have 
been  addressed.  Nevertheless  most  applications  found  themselves  sufficiently 
well  synchronized  by  using  means  like  the  Network  Time  Protocol  (NTP)  or  the 
Global  Positioning  System  (GPS).  Not  only  the  recent  interest  in  using  Ethernet 
for  industrial  automation  or  even  in  sensor  networks,  but  also  the  advent  of  the 
Institute  of  Electrical  and  Electronics  Engineer's  (IEEE)  Standard  for  a 
Precision  Clock  Synchronization  Protocol  for  Networked  Measurement  and 
Control  Systems  (IEEE  1588)  let  high  accuracy  clock  synchronization  be  a new 
discussed  under  the  light  of  new  applications  and  technical  constraints. 

This  paper  presents  a flexible  and  scalable  network  simulation  environment, 
which  allows  for  detailed  and  fast  investigation  of  the  major  parameters  of  clock 
synchronization  for  any  given  network  technology  or  topology.  The  simulation 
environment's  architecture  will  be  presented  and  simulation  results  together 
with  their  possible  influences  on  existing  technology  or  standards  will  be 
discussed. 

Pritam  Baruah, 

Pruthvi  Chaudhark 

Paul  Corredoura,  John 
C.  Eidson,  Andrew 
Fernandez,  . 

Bruce  Hamilton,  John 
Stratton, 

Dieter  Vook 

Agilent 

Technologies 

High  Accuracy  Clock  Synchronization  using  IEEE  1588 

There  exist  applications  in  the  field  of  measurement  instrumentation,  military 
systems,  and  telecommunications  with  synchronization  accuracy  specifications 
extending  to  the  nanosecond  or  sub-nanosecond  range.  This  paper  discusses  the 
practical  difficulties  in  achieving  this  level  of  synchronization  and  proposes 
extensions  to  IEEE  1588  to  make  this  possible.  Experimental  results  on 
prototype  implementations  will  be  discussed. 

Afshaneh  Pakdaman,  San  Francisco 
Todor  Cooklev;  State  University 


IEEE  1588  over  IEEE  802.11b  for  synchronization  of 
wireless  local  area  network  nodes 


John  Eidson 


Agilent 

Technologies 


IEEE  1588  is  a new  standard  to  synchronize  independent  clocks  running  on 
separate  nodes  of  a distributed  measurement  and  control  system  to  high  degree 
of  accuracy.  It  used  a precision-time  protocol  (PTP).  In  this  paper  it  is  advanced 
a method  to  implement  clock  synchronization  over  IEEE  802.11b  Wireless 
LAN  (WLAN).  Practical  experiments  are  presented.  One  conclusion  is  that 
IEEE  1588  can  be  implemented  over  802.1  lb  with  an  accuracy  of  400ns. 


Puneet  Sharma  Intel  Hardware  Assisted  IEEE1588  Implementation  in  a Next 

Corporation  Generation  Intel  Network  Processor 

This  paper  will  describe  the  hardware-assisted  IEEE  1588  implementation  in  a 
future  planned  Intel®  network  processor.  A brief  overview  of  the  IEEE  15  88 
standard  is  provided,  with  particular  emphasis  on  Ethernet  applications.  The 
general  pros  and  cons  of  purely  hardware  vs.  software-oriented  IEEE  1588 
implementations  are  also  discussed  and  applied  to  Intel's  co-hardware  and 
software  IEEE  1588  implementation.  A detailed  description  of  the  IEEE  1588 
hardware  logic  and  the  Intel  XScale®  core-based  software  programming  model 
is  included.  Finally,  some  examples  of  targeted  industrial  applications  for 
IEEE  1588  are  described. 

Note  regarding  the  20-minute  paper  presentation  at  the  Conference: 
The  20-minute  presentation  will  NOT  include  a brief  overview  of  the  IEEE  1588 
standard  as  attendees  should  be  familiar  with  the  standard. 


Hans  Weibel  Zurich  Implementation  design  and  performance  issues 

University  of 

Applied  Science  There  exist  applications  where  independence  of  specialized  hardware  is  more 
important  than  accuracy.  The  Zurich  University  of  Applied  Sciences  has 
evaluated  the  performance  of  software  based  time  stamping  methods.  The  test 
setup  consists  of  an  IEEE  1 588  implementation  which  is  capable  to  deliver  three 
time  stamps  per  transmission/reception  of  time  critical  messages 
simultaneously:  The  first  time  stamp  is  taken  by  hardware  at  the  Mil,  the  second 
at  the  entry  point  of  the  network  interface  driver's  interrupt  service  routine  and 
the  third  one  is  delivered  by  PCAP.  A comparison  of  the  time  stamps  allows  the 
perfonnance  of  different  methods  to  be  evaluated.  The  PTP  protocol  engine  is 
able  to  select  one  of  the  three  available  time  stamps  as  the  source  to  calculate 
offset  and  delay.  The  synchronization  behaviors  and  accuracy  of  different 
configurations  can  be  analyzed.  An  interesting  configuration  is  a hardware 
based  master  clock  (e.g.  a boundary  clock  located  in  a switch)  combined  with 
purely  software  based  slave  clocks. 


Antonius  Boiler  Siemens  Industrial  automation  requires  synchronization  of  line 

topology 

The  high  data  transfer  rate  attainable  through  the  Ethernet's  physical  properties 
opens  new  dimensions  for  real-time  applications. 

A future-oriented  concept  must  have  at  its  core  a wide,  generally  accepted  basis, 
and  must  be  expandable.  Seen  from  this  point  of  view,  there  is  no  alternative  to 
switching  technology.  The  advantages  of  higher  data  transfer  rates,  full-duplex 
communication  and  collision-free  access,  however,  are  bought  at  the  expense  of 
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John  D.  MacKay 


Dirk  S.  Mohl 


an  iinsymmetrical  communication.  Due  to  the  fact  that  frames  are  buffered  in 
the  switch  and  the  length  of  time  they  remain  there  depends  on  the  network  load 
this  may  even  lead  to  frame  loss  in  critical  situations.  This  is  a most  unfortunate 
peculiarity  in  the  case  of  real-time  applications  and  the  reason  why  it  is  not 
possible  to  fulfil  the  requirements  of  the  switched-Ethernet-based  motion 
control  applications  with  the  existing  IEEE  1588  method.  Especially  in  the 
industrial  automation  a basic  requirement  of  the  network  is  the  ability  for  line 
topology.  Hence  a cascade  of  switches  has  to  be  synchronized.  With  today’s 
IEEE  1588-method  the  required  accuracy  for  a line  of  switches  causes 
problems. 

The  presentation  shows  the  need  for  real  time  Ethernet  in  the  industrial 
automation  and  the  problems  when  using  IEEE  1588  for  synchronization  issues 
in  this  area.  Furthermore  it  shows  a method  which  solves  these  problems. 

Progeny  Systems  Interfacing  Mil  Standard  Equipment  to  an  IEEE  1588 

Enabled  Ethernet  Network 

This  paper  will  discuss  the  unique  requirements  for  interfacing  a number  of 
military  standard  devices  to  a 1588  network.  The  current  trend  for  signal 
processing  on  military  platforms  is  to  maximize  the  usage  of  Commercial  Off 
the  Shelf  (COTS)  products  rather  than  developing  full  mil-grade  equipment. 
This  approach  provides  a great  deal  of  advantage  to  the  system  developer, 
because  it  provides  access  to  a variety  of  low  cost  high  performance  devices 
that  have  a great  deal  of  field  experience  and  customer  support.  The  drawbacks 
to  this  approach  occur  at  the  edges  of  the  system,  where  these  COTS  devices 
must  interface  either  with  very  specialized  sensor  and  transducer  equipment,  or 
with  ‘legacy’  standard  busses  and  protocols. 

A COTS  system  with  Ethernet  as  the  core  network  can  be  subject  to  this  issue, 
but  this  can  be  compounded  by  the  need  to  provide  highly  accurate  timestamp 
information  via  1588.  Typically  the  legacy  devices  are  clocked  by  their  own 
internal  timing,  and  drive  the  system  time  via  COTS  interface  cards. 
Timestamps  therefore  occurred  at  the  ‘front  end’  of  the  process  string,  and 
became  embedded  in  the  data  stream.  While  the  insertion  of  timestamp  data  in  a 
1588-enabled  system  would  likely  be  the  same,  the  source  of  time  would  need 
to  be  either  a 1588  network  device  or  a legacy  device  modified  to  be  1588- 
enabled.  There  are  issues  with  both  of  these  solutions. 

These  options  will  be  discussed  for  this  use  case  as  well  as  others.  A use  case 
that  would  require  the  1588  protocol  to  be  implemented  on  a mil-standard 
asynchronous  bus  will  also  be  discussed. 


Hirschmann  Implementation  Results  of  an  IEEE  1588  Boundary  Clock 

Electronics 

Boundary  clocks  are  necessary  to  distribute  the  precise  time  over  network 
components  like  switches  and  routers.  To  build  such  a boundary  clock  inside  an 
Ethernet  switch  beside  the  standard  functionality  several  additional  points  have 
to  be  taken  into  account. 

Ethernet  Switches  typically  use  SNMP  as  management  protocol,  so  relevant 
parts  of  the  IEEE1588  managed  objects  have  to  be  accessible  through  SNMP. 
Also  a switch  often  gets  or  provides  time  over  SNTP.  The  question  now  is  how 
to  combine  these  two  protocols  and  not  to  loose  IEEE  1 588  precision.  The  more 
IEEE  1588  Switches  are  used  the  network  the  more  the  issue  of  cascading 
Boundary  Clocks  and  its  effect  on  precision  and  system  startup  has  to  be 
analyzed. 
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The  necessity  of  cascading  boundary  clocks  often  is  imposed  from  the  network 
topology  of  the  application.  One  aspect  of  using  IEEE  1588  is  derived  from 
Industrial  Automation  Technology.  There  lAONA,  the  independent  platform 
organization  for  Industrial  Ethernet  may  give  ideas  about  usage,  applications 
and  topologies  of  the  network. 

Sven  Nylund  OnTime 

Oyvind  Holmeide  Networks  AS 

IEEE  1588  Ethernet  switch  transparency- 
No  need  for  Boundary  Clocks! 

One  of  the  main  IEEE1588  properties  is  related  to  the  handling  of  variable 
network  latency  between  the  Grand  Master  clock  and  the  Slave  clocks.  I.e.  the 
network  load  dependable  latency  through  the  network  elements  (e.g.  Ethernet 
switches).  This  is  handled  if  IEEE  1588  Boundary  clocks  are  used  on  the 
network  path  between  Grand  Master  and  the  Slave  clocks.  However,  this 
means  that  each  network  element  in  the  network  must  support  full  Master,  Slave 
and  the  Best  Master  Algorithm  with  increased  complexity  and  cost  as  the  result. 

A simpler  and  cheaper  approach  is  based  on  using  network  elements  with 
lEEEl  588  transparency  and  still  achieves  the  same  level  of  timing  accuracy  on 
the  Slave  clocks  and  being  compliant  with  the  IEEE  1588  standard.  This  paper 
describes  the  principles  of  a network  element  with  IEEE1588  transparency. 

Karl  Weber  Siemens 

Bridging  Networks  with  FTP 

Discuss  influence  of  switches  in  networking  today  and  how  it  correlates  to 
1588.  General  procedures  running  at  switches  and  infrastructure  of  such 
switches.  Discuss  need  for  time  synchronization  in  switches  Propose 
Architecture  for  "PTP  Bridges"  that  enhance  accuracy  and  reduce  resource 
utilization  in  switches.  Criteria  for  a PTP  Bridge  protocol  that  will  be  accepted 
by  most  switch  manufacturer 

Thomas  Muller  Zurich 

University, 

Winterthur 

PHYs  and  Symmetrical  Propagation  Delay 

PTP  requires  a symmetrical  propagation  delay  or  at  least  a system  with  known 
differences  between  a pair  of  links.  Ethernet  Physical  Layer 

transmitter/receiver  are  not  symmetrical.  The  same  can  be  found  in  cable 
specification. 

Some  parameter  may  not  known  and  are  not  specified  in  the  related  standards 
nor  by  some  device  specifications.  Measurement  show  a high  accuracy  but  also 
some  significant  difference  especially  in  case  of  auto-negotiation  and  auto- 
crossover. 

A criteria  list  for  transmitter/receiver  is  set  up  to  achievable  high  precision  time 
synchronization.  I will  do  this  together  with  other  colleagues. 

Dave  Tonks  Semtech 

Advanced 

Communications 

Division, 

Southampton 

UK 

IEEE  1588  in  Telecommunication  Applications 

IEEE  1588  is  being  considered  for  various  applications  within 
telecommunication  networks,  including  delivering  a common  time  base  across  a 
network  for  billing  purposes  and  for  synchronizing  service  points  which  have 
become  isolated  by  use  of  a packet  network.  This  paper  investigates  a few  of 
these  applications  and  discusses  a number  of  issues,  including  expected 
limitations  on  network  topology,  and  known  or  likely  performance  goals,  and, 
most  importantly,  probable  barriers  to  adoption.  The  paper  goes  on  to  discuss 
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how  these  issues  eould  be  tackled,  and  in  particular  how  the  current  IEEE  1 588 
standard  could  be  adapted  to  simplify  its  adoption  in  telecommunication 
applications. 

The  migration  of  telecommunication  networks  away  from  their  traditional 
circuit-based  architecture  and  towards  an  all-encompassing  packet  network  has 
begun.  The  principal  drivers  behind  this  are  significant  cost-reductions  in  both 
capex  and  opex,  and  simpler  roll-out  of  new  services.  When  completed,  it  will 
be  seen  to  have  been  a massive  overhaul  of  networking  technology,  covering  all 
aspects  of  the  network,  from  switching  and  transmission  to  operational, 
administration  and  maintenance  activities.  However,  many  of  the  services 
which  have  been  enjoyed  for  many  years  will  continue  to  exist  and  these  are  not 
well  served  by  packet  networks.  They  have  critical  time  dependencies  which,  if 
not  satisfied,  will  cause  the  service  to  fail  to  maintain  the  high  levels  of 
customer  satisfaction  they  enjoy  today.  The  problem,  then,  is  in  finding  ways  to 
satisfy  the  critical  time  dependencies  in  a packet  network.  IEEE  1588  offers  a 
cost-effective  way  to  deliver  timing  in  packet  networks,  providing  certain 
limitations  can  be  overcome. 

Packet  networks  differ  considerably  from  traditional  circuit-switched  networks. 
The  possibility  of  departing  from  the  ‘fixed’  route  per  call,  and  the  use  of 
service  level  agreements  in  which  it  is  necessary  to  know  not  only  just  how 
much  traffic  of  each  particular  type  was  delivered,  but  also  how  much  of  it  met 
the  delay  targets,  means  that  network  operations  such  as  traffic-counting  have  to 
be  moved  to  the  edge  of  the  network.  This  demands  that  accurate  time  be  made 
available  right  at  the  edge  of  the  network.  IEEE  1588  can  provide  that  time. 

Carrying  time-dependent  services  in  a packet  network  is  often  done  using  a 
circuit-emulation  technique.  But  this  is  best  done  when  a common  clock  is 
available  at  both  ends  of  the  connection.  Traditional  networks  inherently 
provide  this  clock  but  packet  networks  cannot.  Adaptive  clocking  techniques 
are  available  but  suffer  from  network  behaviors  and  can  only  offer  a lower 
performance.  Customer  complaints  could  be  common.  Alternatively,  IEEE  1588 
can  provide  the  common  clock  at  the  ends  of  the  connection  and  so  help 
maintain  quality  of  delivery.  This  paper  explores  these,  and  other,  applications. 


John  Stratton,  Agilent 

John  Swanstrom,  Technologies 


Automatic  Test  Systems  using  LAN-based  Synthetic 
Instruments  and  the  Role  of  IEEE  1588 


With  the  current  trend  to  drive  down  the  total  cost  of  ownership  of  Automatic 
Test  Systems  (ATS),  industry  standard  open  architectures  have  been  seen  as 
both  a way  of  driving  down  the  cost  of  test  (for  design  and  manufacturing)  and 
reducing  the  size  of  the  ATS  platforms  (eliminate  the  redundant  hardware). 

A LAN-based  synthetic  instrument  architecture  offers  an  alternative  to  the 
traditional  approach  that  allows  systems  integrators  and  manufacturers  to 
minimize  the  total  cost  of  ownership  from  digital  to  the  highest  performance 
millimeter  wave  applications.  IEEE  1588  is  proposed  as  the  long-term  solution 
for  synchronization  is  the  LAN  environment. 

This  paper  will  analyze  the  current  trends  in  computer  architectures  and  how  it 
is  used  in  synthetic  instrument  based  ATSs.  It  will  show  how  future  trends  in 
component  technologies  will  drive  how  synthetic  instruments  might  be 
designed.  And  finally,  it  will  show  how  customers  and  instrument  providers  can 
quickly  implement  current  capability  and  next  generation  test  technology. 
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Primary  Timing  Reference  Sources  for  IEEE-1588  Systems 

This  presentation  reviews  and  compares  Primary  Time  Reference  sources  for 
IEEE  1588  systems.  Primary  Time  Reference  sources  such  as  GPS,  Loran  and 
cellular  GSM/CDMA  are  reviewed.  The  technical  merits,  characteristics, 
perfomiance  differences,  costs  applications  and  availability  are  contrasted.  The 
use  of  these  primary  time  references  in  the  design  of  a grand  master  clock  and 
resulting  predicted  precision  of  IPPS  outputs  is  examined.  The  application  of 
various  oscillator  types  to  IEEE- 1588  systems  is  compared  in  light  of  primary 
timing  reference  selection,  and  holdover  performance. 
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A Flexible  and  Scalable  Network 
Simulation  Environment  for 
Clock  Synchronization 


Roland  Holler,  Georg  Gaderer,  Hannes  Muhr, 

Nikolaus  Kero 


ICT 

Institute  of 
Computer  Technology 


Synchronization  in  Distributed 


■ Various  approaches 

« NTP 

B IEEE1588 

r SynUTC 

■ Different  characteristics 

* Purely  software  based 

^ Limited  hard-  and  software  resources 
Fault  tolerance  and/or  redundant  signals  paths 
Clock  architectures 
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Requirements  for  Control  applications 

■ Basic  Data 

^ Achievable  accuracy 
r Upper  bound  for  inaccuracy 
r Network  load  overhead 

■ Advanced  Questions  for  Time  Sync 

* Time  distribution  over  heterogeneous  networks 

■ Ethernet,  Powerline,  Fieldbus 
i Behavior  under  any  network  load  condition 
Start-up  and  transient  response 
e Response  to  complex  (multi  node)  error  conditions 

* Influence  of  COTS/custom  network  components 

Institute  of  Computer  Technology  3 


Time  Synchronization  Issues 
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Synchronization  Feature 

Theoretical  (e.g.  SynUTC) 
m A set  of  "limiting"  assumptions  have  to  be  made 
® Reliable  results  for 

■ steady  state  behavior 

■ Worst  case  behavior 

■ Response  to  single  or  well  defined  failures 

Measurement 

® Statistical  data  easily  attainable 
p Internal  state  Information 

■ Clock  and  sync  status 

■ Sync  packet  loss  and  the  like 
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lEEElSQQ! SynUTC  Transparent  Switch 


2 MByte  Rash 


32  general 
purpose  I/Os 


Altera  CPLD 
EPM7064AE 
Confrg 


12V  DC  power 
supply 


RJ45  jacks 


2 RS232 
interfaces 


FPGA  ITAG 
interface 


CPLD  JTAG 
interface 


8 X LSI  Logic 
10/100  Mbit 
Ethernet  PHYs 


25  MHz  XO  for 
Ethernet  PHYs 
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Synchronization  Feature 


■ Limitations  of  measurement  based  analysis 

ii  Start-up  behavior  at  any  given  boundary  condition 
^ Arbitrary  start-up  sequences 
• Transient  response  (to  multi-node  failures) 
r Varying  load  conditions 
p Varying  accuracies  and  asymmetric  delays 
& Fault  tolerance 

■ Best  Master  Group 

■ Redundant  signal  paths 

e Heterogeneous  networks 

■ Simulation  does  the  trick 
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Network  Simulation  (I) 

■ Things  to  consider  / model 

Network  topology  description 

■ Model  types  for  every  node  /module 

j Application  layer 

^ Software  layer 

■ protocol  implementation  and  clock  sync  algorithms 
m Hardware  link  layer 

■ Local  clock  timing  and  architecture 

■ Digital  clock  domains  and  domain  transitions 
p Physical  layer 

■ Latency  and  transmission  delay  jitter  and  skew 

Institute  of  Computer  Technology  11 


Network  Simulation  (ID 

- v \ 1 1 iiiiii  imi'i'miHi^— M 

■ Varying  levels  of  abstraction 

. Software  description 

Dedicated  clock  and  time  stamping  hardware 
Network  controller 

■ Different  tools 

SystemC  / System  Verilog 
- C/C++ 

VHDL  /Verilog  at  RTL-Level 
^ Network  models  (OMNET++) 
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Network  Simulation  (III) 

■ Requirements  for  a simulation  environment 

Network  topology  description  tools 

Message  passing  mechanism 

Foreign  models  and  simulators  linkable/attachable 

■ C/C++ 

■ SystemC  / System  Verilog  Library 

■ Modelsim® 

Sophisticated  analysis  tools 

■ Graphical  analysis 

■ Log  Files 
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Network 


■ OMNET++  chosen  as  simulation  environment 
® Public  domain  for  research 
^ Open  source  (allows  for  attaching  of  simulators) 
Models  available  on  application  layer 
Graphical  front  end 
Feature  List 

■ modeling  discrete  event  systems. 


■ traffic  modeling  of  telecommunication  networks 


■ protocol  modeling 

■ modeling  of  queuing  networks 


■ modeling  of  distributed  hardware  systems 
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SynUTC Ou-\.\\e-?\y  Timestamping 

Sync  and  delay  packets  shall  contain: 


RCV  TS 

RCV  ACC+ 

RCV  ACC- 

DELTA  TS 

SND  TS  SND  ACC+  SND  ACC 


Small  additional  hardware 
Much  easier  for  software 
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3.  Hardware  assisted  Time  Stamping 

■ The  test  setup 

• Results 

4.  Software  Time  Stamping  (NIC  Driver) 

“ The  test  setup 

■ Results 

• Factors  affecting  time  stamp  accuracy 
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1.  Factors  determining  Sync  Precision 

— RTF’s  Performance 
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Performance  depends  on  ... 

■ the  communication  channel’s  symmetry 
(i.e.  same  delay  in  both  directions  and 
constant  over  a longer  period  of  time) 

■ drift  compensated  clocks  (i.e.  same  time 
base  in  master  and  slave  clocks) 

■ time  stamp  accuracy 

■ time  stamp  resolution 

■ sync  interval 

■ clock  stability 

■ clock  control  loop  characteristics 


2004  Conference  on  IEEE  1588.  Seotember  28.  2004 


1.  Factors  determining  Sync  Precision 

— PTP’s  operational  Environment 
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Slave  Clock 
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2.  The  Test  Platform 

— The  Evaluation  Kit 
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Timing  Analyzer  Board; 

Hardware  clock  and  time  stamping 
unit  (time  stamp  resolution  20ns) 


2.  The  Test  Platform 

— The  Evaluation  Kit  (confd) 
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3.  Hardware  assisted  Time  Stamping 

— Clock  and  Time  Stamping  Unit 
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3.  Hardware  assisted  Time  Stamping 

— Start-up  (via  Hub) 
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3.  Hardware  assisted  Time  Stamping 

— Synchronization  (via  Hub) 
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3.  Hardware  assisted  Time  Stamping 
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— Network  Setup:  Switch  under  Load 
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3.  Hardware  assisted  Time  Stamping  ^ | ]/[^ 

— Synchronization  (via  Switch,  with  Load) 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Time  Stamping  in  the  Rx  Path 
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1 

InterruDt  service  routine  of  the  NIC: 

- save  the  current  time  immediately  after  ISR-entry 

- get  the  frame  from  NIC 

- extract  the  necessary  PTP  data  for  the  time  stamp  from  arrived  frame 

- pass  packet  to  upper  layer  (e  g.  IP) 

LINUX  OS: 

- continue  with  previously  interrupted  activities 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Time  Stamping  in  the  Tx  Path 
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/Application  sends  a packet 
I (e  g.  using  sockets) 
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4.  Software  Time  Stamping  (NIC  Driver)  2 m 

— Measurement  Setup 
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incoming  packets; 

RX  latency  = (NIC  driver  time  stamp)  - (HW  time  stamp) 




outgoing  packets: 

TX  latency  = (HW  time  stamp)  - (NIC  driver  time  stamp) 
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4.  Software  Time  Stamping  {NIC  Driver) 

— Rx  Latency 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Tx  Latency 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Rx  Latency  (Node  under  Load) 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Tx  Latency  (Node  under  Load) 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Synchronization:  Hub^  no  Load 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Setup:  asymmetric  Configyration 
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4.  Software  Time  Stamping  (NIC  Driver) 

— Synchronization  (no  Load) 
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5.  Conclusions 

— Lessons  learned 


How  to  reach  better  SW  timestamp  accuracy 
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Action 

Result 

Use  fast  (i.e.  good  performance 
in  general)  PTP  nodes. 

The  better  the  performance  of  the 
node,  the  lower  the  ISR  latency 
and  its  jitter. 

Do  not  allow  long  period  disk  I/O 
(and  other  load  that  raises  ISR 
latency)  on  the  PTP  nodes. 

Peaks  in  ISR  latency  can  be 
detected  and  filtered  out  if  they 
don’t  happen  over  a long  period 
of  time. 

Do  not  allow  long  periods  of  high 
network  load  on  the  Ethernet 
segment. 

Less  collisions  result  in  less  Tx 
latency  peaks. 

Less  Rx  latency  peaks  at 
incoming  traffic. 

5.  Conclusions 

— Lessons  learned  (cont’d) 


How  to  reach  better  SW  timestamp  accuracy 
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Action 

Result 

Detect  ISR  latency  peaks  and 
bypass  adjustment  control  for  the 
clock  if  a peak  happens. 

No  leaps  in  time. 

But  if  peaks  occur  successively 
over  a long  period  of  time,  the 
clock  may  drift  away. 

If  the  interrupt  latency  of  the 
nodes  are  known,  path 
asymmetry  can  be  included  in  the 
offset  calculation. 

No  constant  offset  from  master 
due  to  path  asymmetry. 

->  Only  possible  in  a fix 
environment  (each  node  knows 
its  own  Rx  / Tx  latency). 
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5.  Conclusions 

— Summary 
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Time  stamp  accuracy  degradation  is  caused  by 
■ System  load  (especially  I/O) 

->  Rx  latency  rises 

* Network  traffic  destined  to  a PTP  node 
Rx  latency  rises 

® Network  traffic  on  the  Ethernet  segment 
->  Tx  latency  rises  due  to  collisions 
® Computing  performance  in  general 


SW  time  stamp  accuracy  highly  depends  on 
the  PTP  node’s  SW  environment  and  on 
the  network  structure  and  traffic  pattern. 
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Technological  trends  in  automation 


Trend  away  from  central 
control  structures  to 
distributed  local  units 


Use  of  Ethernet 
at  all  levels  of 
automation 


i Increase  in  use  of  open 
IT  standards  In  automation 


i IT-  and  automation  world 
are  growing  together 
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> Fieldbus  solution 


• Office  and  industrial 
networks 

• Requirements  for 
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■issues  of  1588 

« Requirements  for 
synchronization  in 
automation 

■ Conclusion 
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Benefits  of  Ethernet  in  an  industrial 
environment 

A uniform  network  structure 

m Reduce  the  interfaces 
m Plant  wide  Engineering 
m Continuity  through  to  the  field  level  \ 


Use  the  advantages  of  IT-techno- 
logy  in  the  production  area 

m Remote  Access 
M Web  services 
^ Software  updates 


Improvements  relative  to 
today's  systems 

m High  performance 
m Unlimited  quantities 
s Simple  Handling 
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Automation  and  Drives 


Differences  between  office  and  industrial 
networks 
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■Fieldbus  solution 
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automation 
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Ethernet  in 
automation 
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automation 


Conclusion 
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Fixed  basic  installation 
combined  with  variable 
device  interface 
Star  and  tree  structures 


Plant-specific  cable  routing 
with  individual  networking 
structure 

Star,  ring  and  linear  structures 
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Automation  and  Drives 


PROFINET 


• Fieldbus  solution 
» Market 


• Trends  in 
automation 


‘ Requirements  for 
Ethernet  in 
automation 


« Issues  of  1 588 

• Requirements  for  ^ 
synchronization  in  > 
automation 

■ Conclusion 
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Differences  between  office  and  industrial 
networks 


Office 

Industry 

Fixed  basic  installation  in  buildings 

Extreme  plant  specific  cabling  routing 

Separate  floor  distribution  boxes 

Plant  specific  cabling  routing 

Variable  connection  of  devices 

Connection  points  are  rarely  changed 

Pre-assembled  connection  cables 

Assembly  of  the  connections  in  the  field 

Tree  network  structure 

Often  line  structures 

and/  or  (redundant)  ring  structures 

Big  data  packages  (e.g.  pictures) 

Small  data  packages  (process  values) 

Average  requirements  of  availability 

Extremely  high  requirements 

Moderate  temperatures  (from  0 to  50"C) 

Extreme  temperatures  (from  -20  to  +70°C) 

No  moisture 

Moisture  possible  (IP65) 

No  vibration  loads 

Vibrating  machines 

Low  EMC  load 

High  EMC  load 

Insignificant  mechanical  danger 

Danger  of  mechanical  damaging 

Insignificant  chemical  danger 

Danger  of  chemical  damaging  due  to  oil 
and  aggressive  environments 
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Industrial  Ethernet  - topologies 
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All  topologies  can  be  used 

^ Ring  structure  guarantees  high  availability 
m Line  minimizes  the  cabling  overheads 
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PROFINET 


• Fieldbus  solution 


« Trends  In 
automation 


■ Office  and  industrial 
networks  ' ' 


» issues  of  1588 

■ Requirements  for 
synchronization  in 
automation 

•Conclusion 
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Requirements  for  Ethernet  in  Automation 

Topology 

R All  network  topologies  possible  (star,tree,  line,  ring) 
m Redundancy 

IT  and  Standard  Functionality 
m Open  for  TCP/IP  and  IT  applications 
m Unlimited  network  access  for  any  devices 
Real-Time 

Real-time  features  for  motion  control 
m Maintain  real-time  features  under  any  network  situation 
m Interrupt-free  redundancy 
Technology 

m Use  of  future  oriented  switching  technology 
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Benefits  of  Switching  Technology 

Reason  for  use  of  end-to-end  switching  technology 
State  of  the  art  in  the  world  of  communication 
Prospects  for  further  development 
Prevent  collisions 

Transmit  full  duplex,  parallel  data  exchange 
Quality  of  service  (prioritizing  real-time  messages) 
Switch  integration  in  the  device 
m Simplify  installation  of  devices 
m Minimizes  the  cabling 
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Cascade  of  switches  in  automation 


Requirements  for  motion  control 
m.  Cascade  up  to  25  nodes 
m.  Cycle  time  < 1 ms 
m.  Jitter  < 1 ps 
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Reldbus  solution 


Market 


Trends  In 
automation 


Office  and  industrial 
networks 


Requirements  for 
Ethernet  in 
automation 


Requirements  for 
synchronization  in 
automation 

Conclusion 
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Issues  of  1588 


PROFINET 


1 588  method  for  switches  in  a line 

1 Cascade  of  Boundary  Clocks  (Switches) 

1 Series  connection  of  control  loops 

i Synchronization  frequency  in  seconds 

1 Jitter  accuracy  > 1 ps  for  cascaded  switches  (with  COTS, 
oscillator) 

i Start  up  time  up  to  several  minutes 
i Boundary  Clock  (Switch)  needs  extensive  software 


Boundary  Boundary  Boundary  Boundary  Boundary  Boundary 

Clock  Clock  Clock  Clock  Clock  Clock 
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Synchronization  requirements 
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* Fieldbus  solution 
Market 

* Trends  in  - 
automation  " 

■ Office  and  industrial 
networks 

* Requirements  for 
Ethernet  In 
automation 

•Issues  of  1588 


Requirements  for  synchronization  in  automation 
1 Simple  and  fast  method 
1 Robust  and  stable 

1 Easy  and  cheap  software  implementation  for  every  device 
1 Possibility  for  hardware  implementation 
1 Jitter  accuracy  < 1 ps  for  line  topology 
1 Permanent  operation  of  active  components 
1 Redundancy  aspects 
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Jitter  <1ps 


Tx:  Transfer  time  through  switch  x LZxy;  propagation  time  between 

switch  X and  switch  y 
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IEEE  1588  Ethernet  Switch  Transparency 


Network  with 
Boundary  Clocks 


IEEE  1588  Ethernet  Switch  Transparency 

Impact  on  accuracy: 

1 . No  synchronization  of  local  Transparency  clock 
Example; 

- ATsync  ms 

- Local  clock:  200  PPM 

- Error  = 200  nS 
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IEEE  1588  Ethernet  Switch  Transparency 

Impact  on  accuracy  cont’d: 

2.  Synchronization  of  local  Transparency  clock 
based  on  incoming  SYNC  and  FOLLOW_UP 
packets 

- Accuracy  as  for  a corresponding  Boundary  clock 

- Only  drift  calculation 
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Impact  on  accuracy  cont’d: 
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3.  Synchronization  of  local  Transparency  clock 
based  IEEE1588  Slave  implementation 

- Accuracy  as  for  2. 

- (Reference  to  absolute  time) 
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EEE  1588  Ethernet  Switch  Transparency 


Accuracy:  -100  ns 
with  free  running  clock  (1) 
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- Simple  configuration 

- Faster  setup 
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- Less  interoperability  problems  and  easier 

conformance 
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Switching  (MAC-Bridging)  facts 

• Term  „Switch“  is  used  to  indicate  Bridging  at  Data  Link 
Layer 

• Switches  are  widely  used  today 

• Switches  offer  a set  of  useful  features: 

- support  Full-Duplex  operation  (FDX):  no  CS,  no  MA,  no  CD 
(IEEE802.3X) 

- Little  configuration  effort 

- Priority  support  (IEEE802.1p,  IEEE802.1Q  ) 

- Bridging  different  speeds  and  different  IEEE802  protocols  (e.g. 
wireless) 

- Flexible  structure  through  Virtual  LANs  (IEEE802.1Q) 

- Independent  of  the  network  structure  and  the  size  of  the 
network 

- High  throughput 

- Almost  transparent  to  the  end  nodes 

...  but  not  in  terms  of  delay  and  delay  variation!!! 

(applies  to  Routers  as  well) 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


Assumption:  Output  queue  is  empty  (best  case) 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


->  Delay  = (Framesize  + IFG)/C 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


Assumption:  Output  Queue  serves  a long  frame  (bad  case) 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


Simple  Example 

• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


Simple  Example 


• Store  and  Foreward  Switch  can  be  modeled  as  a Queueing 
system 


->  Delay  = (Framesizel  + Framesize2+2*IFG)/C 


Boundary  Clock 


(S  S'  5 S 0 


Boundary  Clock  (BC) 


• is  more  appropriate  for 
gateways  than  for  switches 

• Boundary  Clocks  add  delays 
which  causes  inaccuracies 

• IP/UDP  is  used  for  most  Sync 
protocols,  but  switches  act  at 
media  access  level 

• Cascading  boundary  clocks 
have  some  negative  impact  on 
accuracy 


Absolute  error  of  Sync  for  different 
number  of  cascaded  bridges  using 
boundary  clocks 
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Jaspemefte.  Weber.  Shehab;  Enhancements  to  the  Time  Synchronization  Standard  IEEE-1588  for  a System  of  Cascaded  Bndges.  IEEE  Workshop 
WFCS  2004.  Vienna 


1588  could  handle  switching  issues 

• 1588  protocol  elements  are  very  useful  in  this  domain 

- Sync/FollowUp 

- DelayReq/Res 

• 1588  does  not  rely  on  UDP/IP 

- Header  with  1588-EtherType  and  1588-MAC  Addresses  has 
the  same  quality 

• 1588  technical  extension  task  force  addressed  this 

- Introduce  new  device  type  PTP  Bridge 

- Add  fields  for  additional  Bridge  Delay  in  Sync/FollowUp 

- Limit  the  scope  of  Delay  measurement  to  adjacent  nodes 


IEEE  802  sync  activities 

• IEEE  802(.1)  has  no  activities  in  synchronization  in 
switched  networks 

• IEEE  802(.3)  introduces  some  synchronization 

- for  link  coordination  as  in  EPON(Ethernet  Passive  Optical  Netw.) 

• IEEE  802(.3)  has  a study  group  for  synch  Ethernet  in 
homes 

- Investigating  sync  protocols 

- Switching  is  an  important  issue  there 

• 1588  could  be  used  ... 

- 1588  has  done  a lot  of  investigations  in  this  field 

- Number  of  sync  protocols  in  IEEE  should  be  limited 


Architecture  of  Time  Sync 
in  Switches  (from  IEEE  802-model) 


(local  Clock  not  required) 


Conclusion 

• There  is  no  widely  accepted  sync  protocol  at  IEEE  802 
level 

• Bridged  networks  need  an  approach  for  sync  at  Bridge 
level 

• A sync  protocol  for  IEEE  802  conformant  sync  shall  fit  in 
the  IEEE  architecture 

- MAC  services 

- Relay  function  at  link  level 

• IEEE  1588  should  do  this  with  a liaison  to  IEEE  802 
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IEEE  1588  Implementation  Results  Network  solution* 

• Overview 

• Network  Management:  SNMP  and  IEEE1588 

• Other  Time  Sync.  Protocols:  SNTP  and  IEEE1588 

• Boundary  Clock  in  Switches:  Results  of  Cascading  IEEE1588 

• IEEE  1588  Usage  in  Industrial  Ethernet  - lAONA 

• Summary 
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IEEE  1588  Switch:  Boundary  Clock  on  Layer  2 -—utions 

IEEE  1588  Boundary  clocks  in  switches 

• only  point  to  point  connections: 

=>  nearly  no  delay  jitter  between  master  and  slave 

• internal  queuing  delay  / jitter  of  switch  not  relevant 

MASTER  CLOCK  BOUNDARY  CLOCK  SLAVE  CLOCKS 


fsl  = SLAVE  CLOCK 
[mI  = MASTER  CLOCK 


,,1588  Switch" 
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Implementation  Features 

Autorrtahon  and 
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Software-  Architecture 

Operating  System  Independent  Design 

- OS  independent  Protocol  Stack 
(IEEE1588  Implementation) 

- OS  Abstraction  Layer 

(Clock  Interface,  Timestamp  Interface,  Port  Interface  (Packets) ) 

- OS  dependent 

(Tasks,  Timer,  Semaphors,  Sockets) 

- OS  and  Hardware  dependent 

(Network  Driver,  Clock  Driver,  Timestamp  Driver  ) 

Hardware-  Architecture 

-T 

-well  defined  Interfaces,  available  Interfaces 
(CPU,  Ethernet:  Medium  or  MAC<=>PHY 

1 

Implementation  Overview 
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Software: 

IEEE1588  Protocol  with  drivers 

Network  Stack:  Operating 
System 

Hardware: 

Time  Stamp  Unit  and  high 
precision  Real-time  Clock 


TSU  - TimeStamp  Unit 


HmscimMm 

Summary  of  Software  stack 

Automation  and 
Network  Solutions 

• IEEE  1588lmplementation 

• based  on  IEEE1 588-2002 

• synchronization,  follow  up,  delay  measurement 

• best  master  clock  algorithm 

• full  IEEE  1588  management  support 

• portable  code 

• adaptation  layer  for  pure  software  or  hardware  based 

time  stamping  / clock  generation 

• SNMP  MIB  (VxWorks) 

• time  representation  of  nsec  : UINT32 

• VHDL;  Timestamp  generation  and  high  precision  clock 

• Implementations  under  Linux,  VxWorks  and  Windows 

1 

Cooperation  ZHW  - Hirschmann 
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Make  IEEE  1588  Code  available 

The  cooperation  was  signed 
in  May  2004 

ZHW  takes  care  of  maintenance,  sale  and 
support  of  Hirschmann  IEEE  1588  stack 

Customer  can  buy  code  (SW)  and  IP  core 
(HW)  as  source  or  binary 

ZHW 

Ziiricher  Hochschule  Winterthur 
/ Zurich  University  of  Applied  Sciences 


IEEE  1588  Management  by  SNMP 
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SNMP  is  by  now  the  most  frequently  used  protocol  on  network  devices. 
There  are  tree  version  of  SNMP  available,  two  of  them  are  common: 


* SNMP  VI  - very  simple  authentication 

SNMP  V2c  - enhanced  variable  types  (not  often  used) 

* SNMP  V3  - secure  authentication,  encryption,  signature,  acces  control 


Since  this  protocol  is  the  basic  management  protocol  in  managed 
switches  and  routers,  it  is  obvious  that  it  also  could  be  used  to  configure 
and  observe  IEEE1 588  parameters.  „ 


E.  g.  drift  and  offset 
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IEEE  1588  Management  by  SNMP 

SNMP  is  organized  in  an  hierarchical 
tree  structure 

Every  object  or  object  group  has  its  name 
and  its  unique  object  identifier 

e.g.  the  object  ID  of 
internet  is  1.3. 6.1 
and  so 

hmNetPTPEnable  is 
1.3.6.1.4.1.248.14.2.3.40.1.1 


The  number  is  used  by  the  protocol  to  access  data 
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internet 
» directors' 

•£ I mgmt 

* experimental 
B private 

E _i  enterprises 
3 '.J  fiirschmann 
S: 1 mike 

S _J  hmConfiguration 
S ihmCnassis 
9 hmAgent 

® hmAction 


« hmActionResult 
_j  hmNetwork 

» hmNetLocallPAddr 
• nmNetLocalPtivsAddr 
« hmNetGatewaylPAddr 
*>  hmNetMask 
® hmNetPPPBaselPA.ddr 
« hmlMetPPPNetwiask 
® hmNetAction 
» hmNetVIanID 
ffi  _J  hmNetHiDiscovervGroup 

ffi  i hmNetSNTPGroup 

9 hmNetPTPGroup 

E _j  hmNetPTPConfiguration 

« hmNelPTPAction 


IEEE  1588  Management  by  SNMP 
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Every  variable  is  part  of  the  Management  Information  Base  (MIB). 

The  definition  of  this  database  is  standardized. 

Every  Object  in  the  database  has  the  following  information: 

Numeric  Identifier,  Name,  Type  (e.g.  integer),  access  (e.  g.  read  only) ... 

It  is  very  easy  to  make  PTP  objects 
available  for  SNMP: 

case  hmNelPTPObservedDrift:  /’  INTEGER,  read-only  */ 

{ 

switch  ( request ) 

{ 

Normally  for  the  target  platform 
(operating  system)  a compiler  is 
available  which  generates  a C-  skeleton 
code  out  of  the  MIB-  file. 

In  this  code  access  to  the  value  has  to  be 
added. 

case  IDB_GET_NEXT: 
buildNextlnstance(...): 

/■  FALLTHRU  */ 
case  IDB  GET: 
if  ( rc  ==  OK  ) 

{ ° 

int  observedDnft=0; 

observedDrift  = PTP_T_getObservedDrift(); 
return  observedDrift; 

> 3 

break:  g 

case  IDB  VALIDATE:  % 

IEEE  1588  how  to  come  to  an  official  MIB 
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Do  It  exactly  the  same  like  IEEE802 
example:  LLDP 

- MIB  Is  part  of  an  IEEE  standard 

- MIB  is  in  the  “std”  branch 


Table  11*3— Basic-TLV  variable/remote- systems  MIB  object  cross-references 


TLV  Namp 

TLV  Variable 

LLDP  ratn«e  wstem  MIBohject 

CLasas  1C‘ 

Chassis  IC'  subtype 

11  dp  RonChasasSubtype 

Chassis  ID 

lldpRemChasasId 

Port  1C' 

Port  IC'subtvpe 

Ildp  RcmPortIdSubtvpe 

12.1  LLOP  MIB  rrmdule^ 

In  the  following  KGB  module,  should  any  discrepancy  be^ween  the  DESCRIPTION  text  and  the  correspond- 
ing definition  in  clauses  10  and  11  occur,  the  definition  in  clauses  10  and  11  shall  take  precedence 


Proposal: 

Iso  ->  std  ->  ieee1588  ->  ptpMIB 
or 

Iso  ->  std  ->  IEC61588  ->  ptpMIB 
object  ID  could  be 
1.0.1588.1  or  1.0.61588.1 

Open  Question: 

Timeframe  vs.  other  options:  RFC 


LLZ*P-MIB  DEFIMITIONS  = BBISIN 
IMP>DRTS 

MCC'ULE-IDEUTir/,  OBJECT-TYPE,  COUnCer32,  NOTIFICATION-TYPE 

FROM  SNMPV2-SMI 

te:^t;al-cc*jvention.  Tin>e£tamp,  Tiuthvalu~ 

FROM  SNMPV2-TC 


I ccitt 

-J  iso 
E-]-  std 

S'_jiso8802 

ieee802dot1 

E _jleee802dot1mibs 
E _J  IldpMIB 

E _J  org 
S3  dod 


IEEE  1588  in  cooperation  with  SNTP 
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NTP  (Network  Time  Protocol)  and  SNTP  (Simple  NTP)  are  currently  the  most 
widely  spread 


SNTP:  typically  +/-  50ms,  about  a minute  to  reach  precision 

NTP:  typically  +/-  50ms,  alos  up  to  ms  and  better,  hours  to  reach  high  precision 


IEEE1588:  +/-  50ns  and  better,  better  than  a minute  to  reach  precision 

Currently  used  time  servers,  atomic  clocks  or  GPS  receivers  use  SNTP  / NTP. 

But  even  if  IEEE1588  servers  will  be  available  a wide  installed  base  will  still  exist.  " 
Also  many  end  devices  need  time  but  no  precision:  will  still  use  SNTP  / NTP 

3 
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IEEE  1588  in  cooperation  with  SNTP  Netwo.so.u..ons 

Requirements 

- precise  absolute  time  including  day 

- precise  relative  time 

IEEE1588  synchronizes  SNTP  server 

=>  with  1588  a SNTP  server  gets  time  nearly  as  precise  as  from  GPS  and  so  can 
distribute  this  time 

SNTP  synchronizes  a 1588  clock 

=>  worse  accuracy  is  transported  to  precise  IEEE1588  network 

Solution: 

Filter  for  SNTP/NTP  time  to  IEEE  1588 

e.  g.  only  Seconds,  minutes  hours  and  days  are  taken  from  SNTP 

3 

Pay  attention  to  “Time  Loops”  : SNTP  =>  1588  =>  SNTP,  e.g.  SNTP  anycast 


IEEE  1588  Test  results:  4 Switches 
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Test  Setup  #1 

1 Grandmaster 
3 cascaded  clocks 

connected  with 
100  Mbits/s 

Every  device  provides 
Offset  and  Drift  over 
SNMP 

Two  devices  generate 
PPS  out 


Grandmaster 


IEEE  1588  Test  results:  direct  connection 
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Switch  2: 

1st  switch  behind  Grandmaster 
observed  Offset  and  Drift 


Peak  to  Peak:  120ns 
=>  + / - 60  ns 


Standard  deviation;  15ns 


(Hi.  HmscHMAm 


IEEE  1588  Test  results:  1 / 2 switches  in  between 
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Switch  3: 

2nd  Switch  after  Grandmaster 

Offset  higher  variation  than 
previous  Switch 

approx.  +/-  110ns 


Switch  4: 

3rd  Switch  after  Grandmaster 

again  Offset  higher  variation 
and  also  higher  drift  variation 

approx.  +/-  150ns 


IEEE  1588  Test  results:  10  switches 


Test  Setup  #2 


1 Grandmaster 
9 cascaded  clocks 


connected  with 
100  Mbits/s 


Every  device  provides 
Offset  and  Drift  over 
SNMP 


Two  devices  generate 
PPS  out 


IEEE  1588  Test  results:  higher  cascading 
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Switch  2 

again  Offset  in  range  +/-  60ns 
Oscillator  sensitive  to  temperature 


Switch  10 

9th  switch  behind  Grandmaster 

Offset  in  Range  +/-  1500ns 
higher  variation  in  Drift 

Runaways  during  temperature  change 


IEEE  1588  Test  results:  higher  cascading 
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Switch  5 

4th  switch  behind  Grandmaster 

measured  Offset  and  Drift 

Peak  to  Peak;  1000ns  =>  +/-  500  ns 


Switch  10 

9th  switch  behind  Grandmaster 

measured  Offset  and  Drift 

Peak  to  Peak:  ns  =>  3000ns  +/-  1500  ns 
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IEEE  1588  Test  results:  short  to  long  path 
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— Offset 

— Drift 


o^cMro^iocDr^ooo^ocNfO^uoQDr^GOO^ 


Switch  10  and  Switch  1 

Fall  over  from  direct  connection  to  in  between  8 switches  and  back. 
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IEEE  1588  Test  results:  different  path 
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— Offset 
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Switch  5 and  Switch  1 

Fall  over  from  connection  over  SW  10  to  SW  6 to  connection  over  SW  2 to 
SW  4 and  back. 
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IEEE  1588  Test  results:  low  vs.  high  traffic 
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no  traffic  high  traffic 

=>  no  influence  observable 


taona  . . 

lAONAand  IEEE1588 
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^ I AON  A Main  Objective  in  1999: 

„Estabiish  Ethernet  TCP/iP  as  the  future  standard 
in  industriai  Communication" 


lAONA  was  founded  in  1999  at  the  SPS/IPC/Drives  in  Nuremberg  as  an 
alliance  of  meanwhile  more  than  130  leading  international  manufacturers 
and  users  of  automation  systems. 

The  task  of  lAONA  is  to  commonly  work  out  specifications  and  guidelines 
to  be  used  in  order  to  force  the  spread  of  Ethernet  in  the  fields  described 
above. 

lAONA  takes  the  view  that  a realization  of  these  aims  can  only  succeed  by 
applying  the  principle  of  the  "open  source"  model.  That  means  a 
consequent  spread  out  of  all  specifications  over  a broad  public 
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IEEE  1588  - Application  example  for  Automation  and 

Real-Time  Cells  ^etwo^scutions 


Several  real-time  segments  are  synchronized  beneath  each  others 


cooperating  robots: 

several  robots  work  together 
the  same  time  with  the  same 
workpiece 


Machines  consisting  of 
several  units: 

e.  g.  printing  machines, 
the  paper  is  hand  over 
from  one  unit  to  the  next 


IEEE  1588  - Summary 
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• IEEE  1588  should  be  supported  by  Ethernet  Switches,  if 
precision  has  to  be  distributed  in  the  network 

• IEEE1588  Stack  available 

• Management  via  SNMP  makes  things  easier 

• IEEE1588  and  SNTP  will  both  be  necessary 

• Cascading  depth  low:  each  switch  adds  its  jitter  of 
about  +/-60ns  to  precision 

• in  higher  cascading  depth  the  accumulated  precision  is  more 
than  the  jitter  of  a switch,  especially  control  loop  events  (e.  g. 
due  to  temperature  changes)  contribute  to  that  jitter. 

• lAONA  may  help  to  promote  acceptance  of  IEEE1 588 
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PHYs  and  symmetrical 
propagation  delay 

Prof.  Thomas  Muller  (ZHW) 

Alexander  Ockert  (Hilscher) 

Prof.  Hans  Weibel  (ZHW) 


Basics 


D.1.1  message  timestamp  point 

Tlie  FTP  message  timestamp  point,  clause  6. 2. 2. 3.  shall  conespond  to  the  leading  edge  of  the 
first  bit  of  The  octet  immediately  following  the  .start  Frame  Deliniitei  octet  of  an  Etlieinet 
packet.  [802,3].  Tins  point  is  illustrated  m Figure  C-1. 


How  to  detect  an  Ethernet  Frame? 


Easy  on  10  Base-X  Technology: 

• Distinct  packages  with  SFD  as  synchronization  point 

• Machester  coding 


Packet 


IDLE 


Packet 


IDLE 


Packet 


10  10  10  11^  SFD 


100  Base-TX:  Continuous,  scrambled  Signal 


Packet 

IDLE 

Packet 
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Packet 
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Locating  „Time  Stamping  Unit“  at  Mil 


when  using  common  PHYs  with  exposed  Mil 
->  only  possible  to  get  time  stamps  at  Mil 


Phy  Transmit  / Receive  Delay 


PHY  with  exposed  MM 
full-duplex,  100  Mbps 

Transmit  Packet 
Assertion 
[bits]: 

Receive  Packet 
Deassertion 
[bits]; 

IEEE  802.3  Standard  (max.) 

14 

32 

NSC  DP83843  PHYTER 

6 

21.5 

Intel  Dual  PHY  LXT973 

5 

17 

• Transmit  Delay  and  Receive  Delay  are  not  equal 
(Difference  of  Factor  3) 

• Delays  are  Vendor  specific 

->  Local  Compensation  needed 


An  idee  that  does  NOT  work  ... 

Master  Slave 

time  stamping  time  stamping 


...when  using  PHYs  of  different  Vendors 

Master  Slave 

time  stamping 
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Another  Source  of  Errors:  Line  Delay  Skew 


Different  twist  rate  of  twisted  line  pairs 

leads  to  Delay  Skew  (difference  between  propagation 

delays  of  transmit  and  receive  lines) 

• CAT  5/6;  up  to  50  ns  per  1 00  meter  cable  (lEC  11801) 

• CAT  7:  up  to  30  ns  per  100  meter  cable  (lEC  11801) 

• Real  cables  are  better  than  lEC  11801  specifies 

• PROFINET  quad-cable:  8 ns  per  100  meter  cable 


Further  details  which  should  be  taken  into 

account... 

If  Mil  and  MAC  represent  two  different  clock  domains  then... 

• MAC  layer  clock  and  Mll.tx_clk  are  not  synchronized 

Error  in  estimation  of  “Transmit  Message  Timestamp” 

• MAC  layer  clock  and  Mll.rx_clk  are  not  synchronized 
->  Error  due  sampling  of  Mll.rxd[0..3]  to  detect 

Start-Of-Frame-Delimiter 


Many  thanks  for  your 
attention! 


Prof.  H.  Weibel  (ZHW) 

Zurich  University  of  Applied  Sciences 
Institute  of  Embedded  Systems 
http://ines.zhwin.ch 


Report  of  the  IEEE  1588  Task  Foree  on 
User  Requirements 

Silvana  Rodrigues  - UR  Task  Force  Chair 
Zarlink  Semiconductor 
Steve  Zuponcic  - UR  Secretary 
Rockwell  Automation 
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Applications  of  Interest 

- Industrial  Controls 

• Robotics 

• General  Motion  Control 

• Industrial  Networking 

• Industrial  Networking  with  RTF  traffic 

- Measurement  and  Control: 

• Process  Control  Applications 

- Test  and  Measurement: 

• RF  Spectrum  correlation,  I/Q 

• Signal  Correlation,  Stimulus-Response,  and  High  Speed  Fogic 

• Fow  Frequency  Devices 

- Military  Test 

2004  Conference  on  IEEE  1 588  2 


Applications  of  Interest  cont’d 

- Telecom 

• Slave  clock 

• Frequency  follower/generator 

• Time  base  follower/generator 

- Automotive 

• On-Board  Control 

- Security 

- Power  grid  substation  automation  and  metering 
automation 


2004  Conference  on  IEEE  1588  3 


Topics 

- Performance 

• A matrix  on  requirements  for  several  applications  was  created 

- API  interface 

• Needs  a better  understanding  of  all  the  system  issues 

• More  study  is  needed  on  this  topic 

- Topology 

• Diverse  requirements  across  applications 

• Need  more  study  on  the  topology  for  different  applications 

- Redundancy 

• No  need  for  redundancy  for  traditional  Test  & Measurement 
equipment 

• Need  more  study  on  how  the  requirements  can  be  met  without 
penalty  for  applications  that  do  not  need  it 
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Performance  Requirements 


Industry/ 

Application 

Performance  Level  (Accuracy) 

Industrial  Controls/  Robotics 

Less  than  lOOps 

Industrial  Controls/ 

General  Motion  Control 

From  Ins  to  lOps 

Industrial  Networking 

From  10|is  to  lOOps 

Industrial  Networking  with  RTE  traffic 

From  Ins  to  Ips 

Measurement  and  control: 

Process  Control  Application 

From  lOps  to  1ms 

Test  and  measurement: 

RF  Speetrum  eorrelation,  I/Q 

Less  than  Ins 

Test  and  measurement: 

Signal  correlation,  stimulus  response, 
high  speed  logic 

Less  than  1 0ns 

Test  and  measurement: 

Low  frequeney  devices 

From  100ns  to  1 ps 

2004  Conference  on  IEEE  1588  5 


Performance  Requirements  cont’d 


Industry/ 

Application 

Performance  Level  (Accuracy) 

Military  test 

Less  than  1 OOps 

Teleeom: 

Time  Aecuraey  at  network  edge: 

Slave  cloek  (freq.  Follower/generator) 

<25ns  short-term 
<2|as  medium-term 
<5|as  long-term 

Time  variance  aeross  clock: 

<25ns  short-term 

< 100ns  medium-term 

< 1 00ns  long-term 

Holdover  Frequency  Accuracy: 

t/-l  X lOe-IO. 

Free-run  Frequency  Accuracy: 

t/-1.6  X 10-8  < 5F  < +/-I  X lOe-7 
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Perfomiance  Requirements  eont’d 


Industry/ 

Application 

Performance  Level  (Accuracy) 

Telecom; 

Time  Accuracy  at  network  edge: 

Equipment  clock  (freq. 

<250ns  short-term 

Follower  generator) 

<2  us  medium-term 
<5  us  long-term 

Time  variance  across  clock: 

<40ns  short-term 

< 100ns  medium-term 

< 100ns  long-term 

Holdover  Frequency  Accuracy: 

+/-1.2X  10-8<5F<+/-4.6x  lOe-6. 
Free-run  Frequency  Accuracy: 

+/-0.2  X 10-9  < 8F  < +/-32  x lOe-6 

Telecom: 

Time  Accuracy  at  network  edge: 

Time  base  clock  (time  base 

<25ns  shon-term 

Follower  generator) 

<2,us  medium-term 
<5  us  long-term 
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Performanee  Requirements  eont’d 


Industry/ 

Application 

Performance  Level  (Accuracy) 

Automotive 

On-board  control 

From  Ins  to  lOps 

Power  grid  substation 

Automation  and  metering  automation 

From  1ms  to  Is 
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New  Requirements  supporting 
the  PAR 

• Sub-nanosecond  Accuracy 

- Test  and  Measurement:  RF  Speetrum 
eorrelation,  I/Q 

- Military  test 

• Telecom  applications 

• Redundancy  for  Robustness 

- Requires  further  study 
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Conelusions 

• Good  understanding  of  the  requirements  for 
several  different  applications 

• User  requirement  study  supports  the  PAR  topics 

• Diverse  requirements  across  applications  for 
redundancy 

- Need  more  study  on  how  the  requirements  can  be  met 
without  penalty  for  applications  that  do  not  need  it 

• Topology  requirements  across  applications  are 
very  diverse. 
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Report  of  the  IEEE  1588  Task 
Force  on  Technical  Extensions 

John  C.  Eidson-  TE  task  force  chair 
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Topics  Discussed 

• Accuracy  issues 

• Redundancy  & fault  tolerance 

• SNMPMIBs 

• Tagged  frames 

• Transparent  boundary  cloeks 

• Telecom  related  issues 

• Mapping  to  DeviceNet 
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Accuracy  Issues 

• Problem  statement: 

- Re-examine  tradeoffs  that  affect  accuracy 

- Re-examine  IEEE  1588  network  components 

- Sub-nanosecond  requirements 

• Possible  technical  solutions: 

- Allow  shorter  sync  intervals 

- Transparent  boundary  clocks 

- Extend  timestamp  resolution 

- Better  oscillators 
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Redundancy  & Fault  Tolerance 

• Problem  statement: 

- Failure  of  the  master  clock 

- Failure  of  a network  path 

- Very  different  requirements  depending  on  application 

• Possible  technical  solutions: 

- Redundant  master  clocks 

- Redundant  time  domains 

- Rapid  re-computation  or  pre-computation  of  delays 
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SNMP  MIBS 

• Problem  statement: 

- Most  Ethernet  based  systems  use  SNMP 

- Most  others  do  not 

- How  does  this  relate  to  IEEE  1588  management 
messages 

• Possible  technical  solutions: 

-Standard  IEEE  1588  MIB 

- Based  on  or  parallel  to  management  messages 
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Tagged  Frames 

• Problem  statement: 

- Variable  length  Ethernet  headers 

- Priority  and/or  VLAN  tagging 

- IPV6 

• Possible  technical  solutions: 

- Modify  Annex  D to  allow  variable  length 
headers 

2004  Conference  on  IEEE  1588 


Transparent  Boundary  Clock 

• Problem  statement: 

- Accumulation  of  delay  with  cascaded  boundary 
clocks 

• Possible  technieal  solutions: 

- ‘Transparent  clock’:  Sync,  Delay  Req 
residence  times  are  measured  and  used  to 
correct  time  stamps. 

- Lots  of  issues  and  details  but  looks  possible 
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Telecom  Related  Issues 

• Problem  statement: 

- Need  higher  accuracy  in  telecom  environment 
(no  boundary  or  transparent  clocks) 

- Need  designed  paths 

- Not  all  paths  are  Ethernet 

• Possible  technieal  solutions: 

- Shorter  sync  interval 

- Layer  2 implementation 

- Shorter  message  length 
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Mapping  to  DeviceNet 

• Problem  statement: 

- Need  to  map  IEEE  1588  to  DevieeNet 

• Possible  technieal  solutions: 

- Feasible  map  exists 
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Conclusions 

• Topies  recommended  for  inclusion  in  a PAR 

- Accuracy  issues 

- Redundancy  & fault  tolerance 

- SNMP  MIBs 

- Tagged  frames 

- Transparent  boundary  clocks 

- Telecom  related  issues 

- Mapping  to  DeviceNet 
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Conformance  Task  Group 


Tasks: 


Handle  questions  and  interpretations  of 
IEEE1588 

Define  minimum  requirements  for  conformance 

Define  test  sets  and  test  setups 

Plug-fests 


OnTime 

nec:Lijar”i“!S 
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Conformance  Task  Group 


Proposal  for  additions  to  the  conformance 
section  of  the  1EEE1588  standard: 


Define  an  appropriate  interface  for  use  in 
monitoring  or  measuring  conformance 

Why? 

Ease  the  task  of  making  reasonable  and  useful 
tests  of  conformance  to  promote 


interoperability 


OnTime 


net 


a r~  K s 


5 

Conformance  Task  Group 

J it. 
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r.  M 

A full  IEEE1588  implementation  provides: 

ft 

• Via  the  management  messages: 

m 

- Currently  only  visible  over  a network 

'j^ 

connection  to  the  device, 

- The  contents  of  the  internal  data  sets  that 

define  all  IEEE  1588  state  governing  the 

k 

i 

protocol:  identity  Info,  and  the  default. 

current,  parent,  port,  global  and  foreign  data 

J 

sets. 

OnTime 

jLj 
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A full  IEEE1588  implementation  provides  cont’d: 

• Via  normal  messages  SYNC,  FOLLOW_UP, 
DEL_REQ,  and  DEL_RESP 

- Timestamps  related  to  SYNC  and  DEL_REQ 
packets  available  from  Masters 

- No  visibility  into  inbound  timestamps  of  the 
Slaves 

- Message  interval  timing,  e.g.  sync  interval, 
delay  request  randomization 


OnTime 
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This  information  will  allow  verification  of: 


Packet  formats  and  consistency  of  packet  data  with 
internal  databases 

Aspects  of  packet  contents  related  to  topology:  e.g. 
identification  of  the  Grand  master,  steps  removed... 

Aspects  of  packet  contents  related  to  time  base:  e.g.  leap 
seconds 

Change  of  state  in  response  to  messages,  e.g.  testing 
the  state  machine  of  clause  7.3  of  the  standard 

Operation  of  the  best  master  clock  algorithms  and  related 
timeouts 

Protocol  timing  details  such  as  sync  interval,  timeouts, 
burst  timing,  etc 

OnTime 
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Conformance  Task  Group 

With  only  this  information  available,  it  is  difficult 
to  verify  the  following: 

1 . Actual  performance  of  device  clocks 

2.  Verification  that  things  like  stratum,  variance,  etc  are 
correctly  specified  in  the  default  data  set  or  the  observed 
variance  and  drift  of  the  parent  data  set  are  correctly 
computed 

3.  The  correctness  of  the  randomization  of  DEL_REQ 
messages  from  slaves  (due  to  the  time  involved  to  gather 
enough  data  to  make  a conformance  decision) 

4.  The  accuracy  of  synchronization  between  two  clocks  (a 
system  issue) 

5.  Bias  in  a clock  introduced  either  by  the  servo  or  internal 

latency  asymmetry  OnTimO 
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How  to  improve  this? 


1 . Actual  performance  of  device  clocks 

2.  Verification  that  things  like  stratum,  variance,  etc  are 
correctly  specified  in  the  default  data  set  or  the  observed 
variance  and  drift  of  the  parent  data  set  are  correctly 
computed 

Proposal: 


Get  access  to  the  clock  oscillator  output  via  a test  point. 
This  allows  the  fundamental  stability  and  noise  properties 
of  the  clock  to  be  measured. 

OnTime 
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How  to  improve  this? 

Ij 

1 3.  The  correctness  of  the  randomization  of  DEL_REQ 

1 messages  from  slaves  (due  to  the  time  involved  to  gather 

1 enough  data  to  make  a conformance  decision) 

1 Proposal; 

, .1 

* 

Management  message  access  to  invoke  the  random 
number  generator(s)  to  measure  its  statistical  properties 

^ f i 

1 i 

^1  -1 

OnTime 
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How  to  improve  this? 

4.  The  accuracy  of  synchronization  between  two  clocks 


Proposal; 


Oscilloscope 

Master  PPS 


^lave  f 


Time  base  PPS 


c 


A pulse  per  second  signal  (PPS)  from  the  clock  along 
with  a specification  of  the  latency  between  the  PPS  port 
and  the  clock. 

OnTime 
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How  to  improve  this? 

5.  Bias  in  a clock  introduced  either  by  the  servo  or  internal 
latency  asymmetry 

Proposal: 

In  addition  to  the  PPS  signal,  visibility  of  the  timestamps 
used  by  slave  servos  as  inputs:  i.e.  slave  received  SYNC 
timestamp  and  slave  receive  precision  SYNC  timestamp 
contained  in  the  FOLLOW_UP  message  from  the  master 
as  well  as  the  corresponding  timestamps  for  the 
DEL_REQ.  This  can  be  via  a new  management  message 
or  perhaps  a callback. 

OnTime 
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How  to  improve  this? 

1 ^ 

I'i 

*■  ’i 

Also: 

J Serious  consideration  should  be  given  to  providing  the 

1 information  above  that  is  derived  from  management 

i messages  from  an  alternate  channel  in  addition  to  or 

1 instead  of  the  network  connection. 

i 

1 

OnTime 
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Proposal  for  user  group  tasks: 


Indentify  and  select  IEEE1588  test  houses 
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A Proposal  to  Open  a PAR  Based  on  the 
Work  of  the  IEEE  1588  Task  Groups 

John  C.  Eidson 


2004  Conference  on  IEEE  1588 


Outline 

• Summary  of  task  force  activity 

• Issues  in  opening  a PAR 

• PAR  proposal 

• Review  of  IEEE  standards  process 

• Questions 
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Summary  of  Task  Force  Activity 

• 3 task  forces  were  created  at  the  request  of 
attendees  at  the  2003  IEEE  1588  conference 

•You  have  heard  the  report  from  each 

• The  members  of  these  task  forces 
recommend  that  a PAR  be  opened. 

•We  will  ask  for  your  views  during  the  open 
discussion  session  tomorrow. 
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Issues  in  Opening  a PAR 

The  Standard  was  published  in  November  2002. 

• The  IEEE  requires  reballoting  every  5 years. 

• Has  there  been  enough  experience  since  2002  to 
warrant  revision/extension? 

• Are  there  compelling  new  application  areas  that 
need  to  be  considered? 

• Is  the  scope  of  the  proposed  revision  appropriate  and 
doable  in  a reasonable  time? 

• Are  there  a sufficient  number  of  technically 
competent  people  willing  and  able  to  serve  on  a 
standards  committee  to  ensure  success? 
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PAR  Proposal 

The  following  are  the  PAR  recommend  topics:  (and 
comments) 

1.  Resolution  of  known  errors:  A list  of  these  and 

recommended  solutions  is  posted  on  the  IEEE  1588 
web  site.  These  are  not 

expected  to  have  appreciable  impact  on  existing 
implementations. 

2.  Conformance  enhancements:  1 PPS  or  equivalent 
signal,  management  message  or  extension  fields  to 
make  internal  time  stamps  visible. 
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3.  Enhancements  for  increased  resolution  and 
aeeuracy:  Extension  fields  to  allow  sub- 
nanosecond time  stamps,  shorter 

svric  intervals  allowed. 

4.  Inereased  system  management  eapability: 
Additional  management  messages,  perhaps 
SNMP 

5.  Mapping  to  DeviceNet:  Pew  if  any  ehanges 
required  in  body  of  standard 
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6.  Annex  D modifications  for  variable  Ethernet 
headers:  Likely  additions  are  tagged  frames  and 
IPV6.  These  could  impact  existing  packet 
recognition  designs  and  protocol  stacks. 

7.  Prevention  of  error  accumulation  in  cascaded 
topologies:  New  clock  type  (transparent  clock), 
topology  and  system  design  guidelines. 

8.  Ethernet  layer  2 mapping:  Possible  optional  shorter 
frame,  shorter  sync  interval.  Must  resolve  needs  of 
industrial  and  telecommunication  applications. 
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9.  Extensions  to  enable  implementation  of  redundant 
systems:  Two  independent  concerns-  master  clock 
failure  and  network  failure.  Additional  management 
or  other  hooks-  force  recornpiitaiion  of 

delay  s/topoiogy...,  use  of  alternate  domains,  ... 

This  is  the  most  uncertain  of  the  possible  areas  as 
far  as  impact. 

10.  Extension  mechanism:  Uniform  way  of  exteridinii 
fields/messages. 
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PAR  Proposal  Topics  Summary 

1.  Resolution  of  known  errors 

2.  Conformance  enhancements 

3.  Enhancements  for  increased  resolution  and  accuracy 

4.  Increased  system  management  capability 

5.  Mapping  to  DeviceNet 

6.  Annex  D modifications  for  variable  Ethernet  headers 

7.  Prevention  of  error  accumulation  in  cascaded  topologies 

8.  Ethernet  layer  2 mapping,  small  frame,  shorter  sync_inter\'al 

9.  Extensions  to  enable  implementation  of  redundant  systems 

10.  Extension  mechanism 
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Review  of  IEEE  Standards  Process 

1 . IEEE  sponsor  (Kang  Lee  for  TC-9  of  I&M  Society) 
appoints  chair  of  working  group. 

2.  Solicit  membership  in  working  group. 

3.  Draft  and  submit  PAR  (project  authorization 
request)  to  the  IEEE 

4.  PAR  approval  (earliest  possible  date  February  4, 
2005) 

5 . Develop  revised  standard  (12-18  months) 

6.  Submit  to  IEEE  ballot  process  (~  3 months) 

7.  Revise/re-ballot  if  necessary 

8.  Editorial/publish  process  with  IEEE  (~  3 months) 
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Questions? 
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A Proposal  to  Create  a Trade  Association  to 
Promote  IEEE  1588  Technology 

John  C.  Eidson 
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Outline 

• Background 

• Example  of  trade  associations  & activities 

• Issues  relative  to  IEEE  1588  teehnology 

• Straw  man  invitation 

• Next  steps 

• Questions 
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Background 

•We  have  received  several  requests  to 
investigate  fomiing  an  IEEE  1588  trade 
association. 

•We  have  heard  varying  reactions  to  this 
idea. 

• During  the  open  discussion  session 
tomorrow  we  want  to  hear  your  views. 


2004  Conference  on  IEEE  1588 


Background 

• Standards  organizations,  and  the  IEEE  in 
particular,  almost  never: 

- Certify  conformance  or  interoperability 

- Conduct  trade  promotion  activities 
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Example  of  Trade  Associations  & Activities 

Typical  trade  associations  goals  or  objectives: 

1.  Legal:  trademark,  licensing,  policy,  ... 

2.  Marketing:  product  catalog,  conferences,  trade 
shows,  publications,  web  sites 

3.  Interoperability:  certification,  technical  working 
groups,  training,  standards  activity 

Typical  organizations  have  a small  professional 
staff  with  much  of  the  work,  including  the  board 
of  directors,  done  by  volunteers  from  member 
companies. 
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Example  of  Trade  Associations  & Activities 

Typical  trade  associations: 

•ODVA 

•Profibus  International 
•ISA 

•WiFi  Alliance 
•MEF 

•I VI  Foundation 

2004  Conference  on  IEEE  1588 


Issues  Relative  to  IEEE  1588  Technology 

• IEEE  1588  application  areas  are  broader  than 
relevant  existing  trade  assoeiations 

• Conformance  and  interoperability  of  produets 
targeted  at  multiple  areas 

• Marketing:  Coordinate  this  conferenee?,  publicity, 
web  site,... 

• Technical 

- Relationship  with  IEEE: 

- Direction  of  the  technology 

- Interim  trials  of  new  mappings,  etc.  prior  to 
standardization 

- Leadership  pool  for  standards  work 
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Straw  Man  Invitation 

Your  company  is  invited  to  send  a representative  to  a kick-off 
meeting  to  explore  the  desirability,  scope  and  organization  of  a 
trade  association  of  companies  and  organizations  involved  with 
IEEE  1588  technology.  The  meeting  will  be  held  at  TBD  on  TBD. 

The  proposed  association  would  be  a legal  entity  composed  of 
dues  paying  member  organizations  and  companies.  There  would 
be  a board  of  directors  governing  the  operation  of  the  association. 
The  proposed  responsibilities  of  the  association  are: 

• Promotion  of  IEEE  1588  technology  (web  site,  conference 
support,  trade  publications,  leadership  pool,...), 

•Promotion  of  interoperability  among  IEEE  1588  devices 
(establishing  conformance  tests  and  testing,  plug-fest,  possibly 
trademarks...), 

•Cooperation  with  other  related  associations  and  standards  setting 
bodies. 
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Next  Steps 

Depending  on  your  comments  in  the  open  discussion 
session  tomorrow  we  will: 

•Do  nothing 
OR 

•Request  each  of  you  to  send  us  the  name  of  the 
appropriate  person  in  your  organization  to  receive  an 
invitation  to  an  exploratory  meeting 

•Solicit  a few  people  to  sponsor,  coordinate,  and  run  the 
initial  exploratory  meeting 

•The  rest  would  depend  decisions  made  by  those 
attending  the  initial  meeting. 

2004  Conference  on  IEEE  1588 


Questions? 
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Plug  Fest  Report 

A.  Moldovansky 
Rockwell  Automation 
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Plug  Fest  Goal 

Demonstrate  interoperability  of  system- 
wide  clock  synchronization  using  the  IEEE 
1588  across  a wide  spectrum  of  devices 
from  various  manufacturers. 
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Participants 

• Agilent  Technologies 

• Hirschmann  Electronics 

• OnTime  Networks 

• Rockwell  Automation 

• Semtech  Corporation 

• Siemens  AG,  Automation  and  Drives 

• Zurich  University  of  Applied  Sciences,  Winterthur 
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IEEE  1588  Plug  Fest  Network 


To  GPS  Antenna 
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Test  Conditions 

• All  nodes  on  the  Plug  Fest  network  will 
operate  on  data  rate  of  1 00Mbps  and  in  the 
full  duplex  mode. 

• All  nodes  will  support  the  Synch  packet 
interval  of  2 seconds  (default). 

• All  nodes  should  support  the  IPPS  output. 
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Results 

• Devices  were  able  to  synchronize  with  each 
other. 

• Accuracy  of  synchronization  is  in  the  range 
between  20-50ns  to  200-300ns  depending 
on  implementation. 
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IEEE  1 588  over  IEEE  802.1 1 b for 
Synchronization  of  Wireiess  Local 
Area  Network  Nodes 

Afshaneh  Pakdaman  and  Todor  Cooklev, 
San  Francisco  State  University 
John  Eidson,  Agilent  Technologies 

afshan@sfsu.edu 


Overview 

Introduction 

• IEEE  1588 

• IEEE  802.11b 

• IEEE  1588  Clock  Synchronization 
over  IEEE  802.1 1 b Wireless  Local 
Area  Network 

• Conclusions 

• Future  work 


LAN  (Local  Area  Network) 

• A computer  network  that  spans  a relatively 
small  area.  There  are  many  different  types  of 
LANs.  Ethernets  being  the  most  common  for 
PCs. 

• IEEE  1588  is  a new  standard  for  precise  clock 
synchronization  for  networked  measurement 
and  control  systems  in  the  LAN  environment. 

• IEEE  1588  has  sub  microsecond  accuracy. 


Wireless  LANs 

• A wireless  local  area  network  (WLAN)  uses 
radio  frequency  (RF)  technology  to  transmit 
and  receive  data  over  the  air.  The  IEEE  has 
established  the  IEEE  802.11  standard. 

• Wireless  LANs  (WLAN)  are  increasingly  used 
to  extend  wired  networks  due  to  easier 
installation  and  freedom  of  movement. 


Topologies  in  Wireless  LAN 


Independent  Basic  Sendee  Set(IESS) 


Wireless  Ad  Hoc  Mode 


V. 

V-  J 

'\.'' 

Basic  SemM  Set  (BSS) 


Wireless  Infrastructure  Mode 


IEEE  1588  Timing  Related  Messages 

• Four  types  of  timing  messages:  Sync, 
Follow_Up,  Delay_Req,  Delay_Resp 

• Issuing  and  response  to  these  messages 
dependent  on  the  ‘state’  of  each  clock 

• The  Sync  and  Delay_Req  messages  are  time 
stamped  when  they  sent  and  received 
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Detection  of  Sync  messages 


i 

Application  layer 

Network  protocol 
stack 

Sync  and 
DelayReq 
message 
detector 

Physical  layer 

e.g.  interface  in 
Ethernet 


e.g.  IEEE  802.11b 
in  Ad  Hoc  mode 


IEEE  802.11b  Standard 

• PHY  layer 

• MAC  Layer 


PHY  and  MAC  layer 

• Data  shall  be  exchanged  between  the  MAC 
and  the  PHY  by  series  of  PHY-DATA 
requests  issues  by  MAC  and  PHY-DATA. 
confirm  primitives  issued  by  PHY. 

At  the  Master  node: 

• The  PHY  layer  indicated 
Last_Symbol_on_Air  event  to  the  MAC  layer 
using  PHY-TXEND. confirm. 


PHY  and  MAC  layer  (continued) 

At  the  slave  node: 

• The  PHY  layer  indicates  the 
Last_Symbol_On_Air  event  to  the  MAC  layer 
using  the  PHY_RXEND.  indication  primitive. 


PLCP  Transmit  Procedure 


MAC 


PHY  PHY 

PLCP  PMD 


PHY_TXSTART 

req 


PHY_TXSTART 

.confirm 

PHY_DATA.req 

Time 

PHY_DATA. 

confirm 


PMD_TXPWRLVL.req 

PMD_RATE.req 

PMDANTSEL.req 

PMD_TXSTART.req 

PMD_DATA.req 

PMD_RATE.req 

PMD_DATA.req 


PMD_RATE.req 
PMD_MODULATION  req 
PMDDATA.req 


TX  Power  RAMP  on  Scramble 
start 


CRC  16 
start 


CRC  16 
end 


TX  Power 
RAMP 
off 


Mapping  IEEE  1588  over  802.11b 
Delay  Spreading: 

• It  is  associated  with  multipath  signal. 

• Processing  Delay 

• Jitter  between  the  Transmitter  and  Receiver 
devices 


Mapping  IEEE  1588  over  802.11b 
(continued) 

• Time  stamp  point 

• Last_Symbol_on_Air 

• This  indication  is  observable  by  all  the 
stations. 

• It  is  readily  available  from  the  PHY  layer  in  the 
form  of  either  PHY_RXEND  indication  or 
PHY  TXEND  indication. 


Timing  Diagram 
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Conclusions 

• State  the  meaning  of  the  results  in  terms  of 
synchronization,  IEEE  1588  can  be 
implemented  over  WLAN. 

• TX_RDY  and  MD_RDY  Falling  edge  looks 
best  for  implementing  IEEE  1588. 

• PHY  jitter  is  500  to  600  ns  and  the  average 
offset  is  7.35  us. 


Future  work 

• Adding  an  annex  to  IEEE  1588  standard  for 
Wireless  Local  Area  Network  implementation 
of  PTP  (precise  time  protocol). 

• Design  the  hardware  assist  circuits  that 
permit  IEEE  1588  to  achieve  sub- 
microsecond synchronization  for  WLAN. 


High  Accuracy  Clock  Synchronization 
Using  IEEE  1588 

Pritam  Bamah,  Jeff  Burch,  Pruthvi  Chaiidhari, 
Paul  Corredoura,  John  C.  Eidson,  Andrew  Fernandez, 
Bruce  Hamilton,  John  Stratton,  Dieter  Vook 
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•Motivation  for  this  work 

•Practical  issues  in  achieving  nanosecond  level 
synchronization 

•Experimental  results 
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Instrumentation  and  testing  of  high  speed  systems: 

•Electromagnetic  signals  propagate  at  foot/ns 

•Network  signaling  rates  in  GHz  range  with  packet 
dimensions  in  low  ns  range 
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Conference 


Extend  IEEE  1588  using 


■ More  stable  oscillators 

■ lOOBT  or  Gigabit- Ethernet 

■ Increased  bit  resolution  of  clocks 

Build  demonstration  version 
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Practical  issues  in  achieving  nanosecond 
level  svnclironization 

•Background 

•Oscillator  characteristics 

•Clock  resolution 

•Network  signaling  characteristics 

•Topology 
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Thermal  eoiisicieratioris 

•Oscillator  drift  is  a major  contributor  to 
synchronization  errors. 

•Quartz  crystal  based  oscillators 

•Uncompensated  oscillators  generally  in  few  ppm/degree  range 

•Thermal  compensation  typically  xlO  to  xlOO  better 

•Atomic  based  oscillators 

•Several  orders  of  magnitude  less  drift  than  quartz 
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Oscillators:  Allan  Deviations  for  Coiiiinoii  Sources 
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Clock  resoliitioii  corisicleratioiis 


•The  LSB  of  the  actual  clock  and  any  datatype 
representation  limits  measurement  and  therefore 
synchronization  accuracy 

•The  minimal  rate  and/or  offset  adjustment  of  the  clock 
and  any  datatype  representation  limits  the  ability  of  the 
servo  to  correct  to  the  desired  accuracy. 
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Signaling  rates: 

•10  BT:  10  MHz,  100  ns  period 

•100  BT:  25  MHz,  40  ns  period 

•1000  BT:  125  MHz,  8 ns  period 

Rise  time  of  the  network  signal  limits  the  accuracy  of 
generating  a reproducible  time  stamp 


13  December  20042004  IEEE  1588  Agilent  TecHnologieS  Page  10 

Conference 


Acf'uracy  Isriies  (topology) 

Single  subnet:  switch  jitter  a problem  at  ns  level 
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ssiies 


Hierarchy:  Error  accumulation  at  ns  level 
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Accuntey  Issyes  (topology) 

Linear:  not  currently  feasible  at  ns  levels 

1.  Cascaded  devices  accumulate  servo  error  & quantization 
errors  a severe  problem  at  ns  level 

2.  Low  accuracy  intermediate  devices  dominate  error 
budget  of  chain 
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Accuracy  Issues 


1.  Path  asymmetry  introduces  offset  errors 
significant  at  ns  level 


2.  The  major  source  of  asymmetry  in  a complex 
network  is  queuing  differences  in 
switches/routers  or  in  actual  routing  differences. 


• At  ns  level  probably  rules  out  all  but  single  level 
hierarchy,  i.e.  direct  master  boundary  clock  to  slave 

3.  Physical  media  can  also  be  asymmetric 

• CATS  cable  asymmetry  is  nominally  25-50ns/100m 

• Measure  and  correct  for  delay 
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Experimental  results 

•Clock  design 
•Measurements 
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design 
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Resolution  (LSB)  = 4 ns.  Sync  interval  2 seconds.  Short  averaging 
time.  Standard  deviation  = 4.4  ns,  mean  = 1.5  ns. 


Next  steps:  1 ns  LSB,  long  averaging  time  in  servo. 
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Master  Clock  Requirements 

IEEE  1588  Protocol  implementation 
Time  Source 

* UTC  Time  Reference,  or  arbitrary  user  defined  time  base 

* 1 PPS  or  On  Time  Point  input 

• May  support  an  optional  secondary  Time  Source 

Port  to  Physical  Transport  - e.g.  Ethernet 
Oscillator 

• Meets  minimum  accuracy,  stability,  and  adjustment  range 
» Satisfies  Holdover  Time  between  max  sync  time  interval 

1 PPS  Output 
User  Interface 
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Time  Source  Characteristics 

Time  sources  typically  have  two  primary 
features 

^ Delivery  of  current  time 

Current  UTC,  Local  or  arbitrary  user  defined  time  is 
delivered  within  a specified  accuracy 

* On  Time  Point  or  1 PPS  input 

Many  time  delivery  protocols  provide  a means  to  indicate 
that  at  a particular  instant  the  current  time  data  is  valid. 
This  is  typically  done  by  an  On  Time  Point  in  a data 
stream  or  by  a 1PPS  input. 


Time  Sources 


Radio  Clocks 


• Radio  signals 

US  - (WWV,  WWVB,  WWVH),  Germany-DCF77,  UK-MSF, 
Japan-JJY,  Canada-CHU,  .etc 

• GPS,  GLONASS.  India’s  NPL  INSAT 

• Loran,  Enhanced  Loran 

• Cellular  Networks  - GSM,  CDMA 

Terrestrial  Time  Servers 


• Private  and  Public  NTP  Servers 

• NIST  Services  Dial  Up  (ACTS),  Internet  (ITS),  and  FMS 

External  Interface  to  a Time  Source 

IRIG.  RS-232.  RS-42^  35.  and  E1/T1  (SDH) 


Radio  Signals  as  a Time  Source 

Benefits 

• Supported  by  National  Labs  and  Standards  bodies 

• Broadcast  is  generally  available  across  wide  area 

* Antenna  and  sky  view  only  is  required 

* Typically  has  good  long  term  stability/accuracy 

Drawback 

• Regionally  available 

* Reception  can  vary  due  to  atmospheric  conditions  and 
interference 

* Indoor  reception  can  be  difficult  or  poor 

• Radio  Receiver  for  Time  Source  signals  can  be  low  cost  or 


expensive  for  full  NTP  Time  Server  systems 
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GPS  as  a Time  Source 


Benefits 

* GPS  receiver  cost  is  dropping  and  sensitivity  increasing 

» Typical  GPS  Receiver  is  a very  accurate/stable  time  source 

* Acts  as  a reference  to  an  Atomic  Clock  Standard 

* Available  vyorldwide 

Drawbacks 

® Dependent  on  US  Military 

Reception  can  be  jammed  & degraded 

* Antennas  must  have  clear  sky-view,  doesn’t  work  indoors 

* Not  ail  GPS  receivers  are  suitable  for  time  sync 

Poor  stability  and/or  accuracy 


Loran  as  a Time  Source 


^ Benefits 

* Available  across  large  areas  of  land  and  sea 

* Accuracy  and  stability  is  similar  to  GPS 

* Ground  wave  signal  Is  stable  and  easy  to  receive 

* Referenced  to  Atomic  Clocks 

* Metrics  and  phase  data  available  daily 

Drawbacks 

* Equipment  cost  can  be  higher  than  GPS  systems 

* Reception  is  limited  geographically 

» Long  term  future  of  Loran  system  is  uncertain 


- . .. 

^ mmak  2 

GSM  and  CDMA  as  Time  Sources 

Benefits 

• Typically  slaved  to  GPS 

• Available  anywhere  GSM/CDMA  reception  works 

• Indoor  reception  possible 

• Provides  a data  link  connection  if  needed 

• About  the  same  cost  as  a GPS  based  solution 

Drawbacks 

* GSM  and  CDMA  are  only  regionally  available 

* Not  all  Cellular  networks  are  synced  to  UTC 

* Does  not  provide  a GPS  independent  backup 

* May  not  provide  1PPS  input 
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External  Interfaces  to  Time  Sources 


Benefits 

^ Provides  direct  ‘foreign’  connection  to  external 
time  source  such  as 

Atomic  Clock,  GPS,  Radio,  GSM/CDMA,  NTP  Server, 
Loran.  .etc 

« On  Time  Points  of  protocols  can  simulate  1PPS 

Drawbacks 


Inputs  could  lack  1PPS  input  or  On  Time  Point 

High  latency  of  some  interfaces  may  require  a 
lower  Stratum  level  than  the  Time  Source 


What  does  Stratum  mean? 


♦ IEEE  1588 

* Indicates  with  Identifier  time  accuracy  relative  to  UTC 

® Identifies  whether  a clock  is  a Primary,  Secondary,  or  is  not 
a Reference  to  a standardized  source  of  time 

. NTP 

* Stratum  & Code  indicate  Reference  status/source 

0 - Undefined,  1 - Primary,  2-255  - Secondary 
- Codes  - e.g.  NIST,  ATOM,  VLF,  WWVB,  LORC,  GPS 

T1.101 

* Stratum  indicates  minimum  accuracy  of  clocking 

Stratum  1 - <1x10-^T  Stratum  2 - <1.6x10A 
Stratum  3 - <4.6x10-^,  Stratum  4 - <3.2x1 0'^ 
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Clock  Identifiers 
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stratum  Levels  and  Clock  Identifiers 


Identifier 

Stratum 

Specification 

Time  Source 

ATOM 

-1 

< 25  ns 

UTC  Atomic  Clock 

GPS 

1 

< 100  ns 

GPS  Receiver 

ATOM 

2 

<100  ns 

UTC  Atomic  Clock 

GPS 

2 

< 100  ns 

GPS  Receiver 

NTP 

2 

<15  msec 

NTP  Server  - Internet 

NTP 

2 

< 50  msec 

NTP  Server  - Dialup 

HAND 

>=  2 

<10  sec 

Setting  time  manually,  or  automated 

!N!T 

>=  2 

Unspecified 

User  Defined 

DFLT 

>=  3 

None 

None 

Stratum  Levels  and  Clock  Identifiers 


Time  Source 

1PPS  - Time 
Uncertainty 

Frequency 

Uncertainty 

identifier 

Stratum 

Typical  GPS  Receiver 

< 20  nsec 

< 1x10"- 

GPS 

1 

GLONASS  (and  GPS) 

20-500  nsec 

10-^  to  10- =2 

GPS 

>=  1 

INSAT 

20  usee 

5x10-'*° 

NTP 

2 

Loran.  Enhanced  Loran 

<100  nsec 

X 

o 

GPS 

>=  1 

CDMA  slaved  to  GPS 

<10-100  usee 

-GPS 

NTP 

2 

GSM  slaved  to  GPS 

< 1 00  usee 

-GPS 

NTP 

2 

AMPS  (Analog  Cellular) 

T1  or 

Local  Clock 

-1x10-° 

>=  INIT 

>=  2 

Un-synced  Cellular  Network 

Undefined 

Unknown 

INIT 

>==  2 
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stratum  Levels  and  Clock  Identifiers 


Time  Source 

1PPS  - Time 
Uncertainty 

Frequency 

Uncertainty 

Identifier 

Stratum 

WWVB,  DCF77 

0.1-15  msec 

10-^'^' to  10-12 

NTP 

2 

WWV,  WWVH 

1 -20msec 

10-®  to  10-^ 

NTP 

2 

CHU  {no  path  delay) 

< 1 msec 

< 1 0'^  sec 

NTP 

2 

IRIG 

20  - 200  usee 

Varies 

NTP 

2 

RS-232,  RS-485 

<0.1-1  msec 

Varies 

NTP 

2 

T1,101  Stratum  1-4 

See  Stratum 

3.2x10-=  to  1x10-11 

NTP 

>=2 

NIST  ACTS 

<15  msec 

NA 

>=  NTP 

2 

NIST  ITS 

<100  msec 

NA 

>=  NTP 

CM 

11 

A 

NIST  FMS 

< 20  nsec 

2x1 0-1 2 to  2x10-11^ 

ATOM 

1 

Oscillator  Choices 

Quartz  Crystals 

• Improvements  include  disciplined  and  temperature 
compensated  crystals  and  PICO  Ensembles  of  Quartz 
Oscillators  nearing  atomic  clock  performance 

TCXO 

• improvements  include  Disciplined  TCXO  systems 

ocxo 

• Improvements  include  Disciplined  OCXO  systems 

• Sophisticated  OCXO  approaching  Atomic  clock 
performance 

Atomic 


Why  is  Holdover  important? 


Holdover 


« The.ability  of  a synchronized  IEEE  1 588  clock  to  stay  within 
it’s  specification  for  Stratum  and  Identifier  until  the  next 
synchronization  message  from  it’s  master  clock  or  time 
source 

Defines  the  maximum  time  until  a Master  Clock  must  lower  it's 
Stratum  and  Identifier  if  not  receiving  a sync  from  it’s  time 
source(s) 

Holdover  requirements  define  accuracy  requirements  for 
clock’s  oscillator 


Determines  Quality  of  Service  from  a Master  Clock  in  cases  of 
loss  of  time  reference 


— 


Stratum  Level  versus  Oscillators 


Oscillator 

Frequency 

•Uncertainty 

Identifier 

Stratum 

Error  Offset 
to  UTC 

Holdover 

Cesium 

<1x10'^2  _ 1x10 

ATOM 

1 

< 25  nsec 

6.94  - 69.4  hours 

Cesium 

<1x10-^2_  1x10-’'^ 

ATOM 

2 

<100  nsec 

27.78-277.8  hours 

Rubidium 

X 

o 

ATOM 

1 

< 25  nsec 

6.94  hours 

Rubidium 

1x10-^^ 

ATOM 

2 

< 100  nsec 

27.78  hours 

OCXO 

1x10-5-1x10-^- 

GPS 

1,2 

< 100  nsec 

10  - 1000  seconds 

TCXO 

1x10-^ 

GPS 

1,2 

<100  nsec 

0.1  seconds 

stratum  Level  versus  Oscillators  (2) 


Oscillator 

Frequency 

Uncertainty 

identifier 

Stratum 

Error  Offset 
to  UTC 

Holdover 

OCXO 

o 

X 

1 

6 

X 

NTP 

2 

<15  msec 

17.36-  1736  days 

OCXO 

1x10-3-1x10-1"' 

NTP 

2 

< 50  msec 

57.87  - 5787  days 

TCXO 

1x10-3 

NTP 
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Summary 

* GPS  Time  Sources  are  preferred,  but  others  like  Loran  and 
GSM/CDMA  have  similar  precision 

* Alternate  Time  Sources  which  provide  1 PPS  or  an  On  Time 
Point  in  the  interface  are  preferred 

® Utilize  a backup  Time  Source  to  provide  redundancy  and 
independence  from  GPS 

* Choose  secondary  time  source  such  that  your  system  can 
still  function  as  a master  clock  in  your  application 

® Design  Master  Clocks  utilizing  an  oscillator  with  properties 
sufficient  for  your  precision,  accuracy  and  holdover 
requirements 
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internationalization 

• might  be  easier  if  Unicode  and  a Language  ID  is  used  for 
Strings 

Clock  identifiers 

• Would  more  Identifiers  for  different  time  sources  be  useful? 

Additional  Data  Sets? 

• Would  Time  Source  manufacturer  & capabilities  be  useful? 

• Would  Vendors  specific  datasets  be  useful? 

• Would  listing  of  all  time  sources  and  priority  be  useful? 
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Adapting  Networks  to  IEEE- 1588 

• IEEE- 1588  is  designed  to  be  network  independent. 

• Each  network  that  supports  1588  provides  a definition 
within  an  annex  of  the  specification  as  to  how  1588  maps 
to  that  network. 

• Current  specification  has  one  Annex  for  a network 
definition:  Ethernet  (UDP/IP). 

• A proposal  has  been  submitted  for  a DeviceNet  Annex. 

• A Communication  Technology  code  has  been  allocated 
for  DeviceNet  (7). 


DeviceNet  Background 

• ODVA  founded  1995 

- Open  DeviceNet  Vendor  Association 

- Approx.  350  member  companies  around  the  world 

• Estimated  8 million  DeviceNet  nodes  installed 

• Targeted  at  low  end  sensor  and  actuator  devices 

- Photoeyes,  limit  switches,  pushbuttons,  bar  code  readers,  etc 

- Motor  starters,  Variable  Freq.  Drives,  pneumatic  valves,  etc 

- Block  I/O  devices 

• Trunkline/dropline  topology  with  power  in  the  network  cable 
for  small  devices  (typically  sensors) 


DeviceNet  Data  Link  Layer 

• DeviceNet  uses  CAN  (Controller  Area  Network)  technology 

• The  1 1 bit  Identifiers  provide  2032  unique  multicast  message 
identifiers  for  the  network. 

• CAN  does  not  allow  more  than  one  node  to  use  the  same 
Identifier. 

• A CAN  frame  (packet)  can  deliver  up  to  8 bytes  of  data. 


CAN  Data  Frame  Overview 
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DeviceNet  Architecture 

• DeviceNet  allows  for  up  to  64  devices  (nodes)  on  the 
subnet. 

• Each  device  is  assigned  part  of  the  2032  message 
identifier  space,  where  the  node  number  of  the  device  is 
part  of  the  message  identifier. 

• Fragmentation  is  provided  to  allow  for  large  messages 
using  multiple  CAN  frames. 

• Messages  can  be  Unconnected,  Explicit  connected,  or 
Implicit  (I/O)  connected. 


DeviceNet  as  a Part  of  CIP 

DeviceNet  is  one  of  several  networks  to  share  a common 
object  oriented  application  layer  called  CIP. 

• CIP:  Common  Industrial  Protocol 

• CIP  is  used  by  DeviceNet,  ControINet,  and  EtherNet/IP 

ODVA  is  standardizing  on  IEEE- 1 588  to  provide  time 
synchronization,  termed  CIP  Sync,  for  all  CIP  networks. 


DeviceNet,  ControINet  & EtherNet/IP  Share 
Common  Application  & User  Layers 
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1588/DeviceNet  Adaptation 

The  adaptation  for  DeviceNet  consists  of: 

• Selection  of  Message  Timestamp  Point 

• Definition  of  UUID 

• Mapping  of  1 588  Ports  and  Multicast  Addresses 

• Definition  of  on-the-wire  format  for  message  data 


Message  Timestamp  Point 

The  message  timestamp  point  shall  correspond  to 
the  trailing  edge  of  the  sixth  bit  of  the  End  of  Frame 
of  the  first  fragmented  packet  of  a PTP  message. 
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Selection  of  UUID 

DeviceNet  (along  with  all  networks  within  CIP)  assigns  a unique  16 
bit  Vendor  ID  to  each  manufacturer  of  CIP  products.  In  addition, 
every  vendor  assigns  a unique  32  bit  Serial  Number  to  each  CIP 
product  manufactured.  Thus,  the  CIP  Vendor  ID  and  Serial 
Number  combination  is  universally  unique. 

Given  this,  the  1588  UUID  (universally  unique  identifier)  for  the 
DeviceNet  adaptation  shall  be  the  Vendor  ID  and  Serial  Number  of 
the  DeviceNet  node  containing  the  1588  clock(s). 

UUID  field  = Vendor  Id  + 

Product  Serial  Number  + 

Node  Id 

1 1 


Mapping  of  1588  Ports/Addresses  to 

DeviceNet 

The  PTP  multicast  addresses  shall  be  mapped  onto  the 
DeviceNet  Unconnected  (UCMM)  message  identifiers, 
with  a UCMM  service  code  uniquely  identifying  the 
combination  of  PTP  subdomain  address  and  PTP  port. 

- Each  DeviceNet  node  has  a unique  message  identifier  on 
the  network  for  sending  1588  messages. 

- A total  of  8 service  codes  are  defined;  one  for  each  of  two 
ports  on  each  of  the  four  subdomains. 


Subdomain  Name  Mapping 

To  save  network  bandwidth,  all  non-management  FTP 
messages  shall  use  an  encoded  8-bit  subdomain  value 
within  the  FTP  header  to  represent  the  FTP  subdomain 
name. 

The  mapping  of  names  to  encoded  values  shall  be 
accomplished  with  Management  messages. 


1 DFLT 

2 ALTl 

3 _ALT2 

4 ALT3 


On  the  Wire  Data  Format 


• All  non-management  FTP  messages  are  packed,  unlike 
Ethernet  which  has  32-bit  alignment. 

- sync  msg  = 1 5 frames 

- followup  msg  ==  5 frames 

• FTP  Management  messages  are  consistent  with 
Ethernet  to  reduce  burden  and  forward  compatibility 
issues  with  boundary  clocks  (routers). 

• This  consistency  may  be  extended  to  be  the  general 
rule  for  communication  technologies  as  a separate  1588 
specification  update. 

14 


CIP  Time  Sync  Object 

ODVA  will  provide  an  Object  definition,  the  CIP 
Time  Sync  Object,  which  will: 

-Allow  CIP  messaging  access  to  PTP 
Management  messaging. 

-Provide  access  to  the  1588  time  within  CIP 
applications  in  the  device. 
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Clock  Synchronization  Algorithin  In  Software  for  the 
Intei®  Network  Processor 

- MasterCiockTime^  = MasterSyncTime^  + MasterToSiayeDelay 

- CiockDiffCounL  = IVIasterClockTimen  SlaveClockTimen 


-Where,  . . c- 

- n - Sync  message  counl:^^  ^ . 

- MasterSyncTime^  ^ time  at  which  Master  senjds  a Sync  message  to 

a Slave  : ~ 

- SlaveClockTimen  - time  at  which  Slave  receives  the  Sync  message 

- MasterClockTi 
is  received 

- FregScaleFactor^  -^l^^sterCloc 
SlaveClockCount^ 

- Where, 

- MasterCiockCount„s  MasterCiockTtme„- MasterCio 

- SlaveClockCount„-  ^laveCJockTime„-  SlaveCiockf 
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Interfacing  Mil  Standard  Equipment  to  an 
IEEE  1588  Enabled  Ethernet  Network 


John  D MacKay 
Progeny  Systems  Inc. 


1 6 September  2004 


Progeny  Systems 


Progeny  Systems 

\ &ip«rinfS<Hations  That  Last  tooratKHis 


• Small  Business  Department  of  Defense 
(DoD)  Contractor  for  NavSea,  NavAir,  Air 
Force,  and  Others 

• Primarily  Work  With  Sonar  Systems 

• Prime  and  Sub-contractor  With  Lockheed 
Martin,  General  Dynamics 

• Based  in  Manassas,  VA 

• Focus  is  to  Develop  Innovation  for  DoD 


1 6 September  2004 


Motivations  for  Utilizing  IEEE  1588  PrOgCfiy  SyStCmS 

in  a Mil  Platform  ' tngtneenngktMoits  that  tart  tomioni 


• Legacy  Systems  Are  Stand-alone,  Custom 
Made  Mil  Grade. 

• When  Implemented,  Common  Data 
Collection  Was  Not  Needed 

• Timing  Sources  Were  Independent 

• Introduction  of  Commercial  Off-the-shelf 
(COTS)  Equipment  Permitted  Access  to 
Better  Data  Processing  and  Sharing 

• Need  Arose  to  Get  a Common  ‘Bird’s  Eye 
View’  of  the  Data  Across  Several  Systems. 

• Without  a Common  Time  Reference,  Data 
Reconstruction  Is  Difficult,  in  Some  Cases 
Impossible. 

16  September  2004 


cT^  Progeny  Syitemj 

Issues  1 &tpecrti!gisl8dsft!  that  tart  toratm 

• Production  Systems  Counted  in  the  lO’s  to  100s.  There  Is  No 
Effort  to  Scale  for  Large  Quantities. 

• Cannot  Leverage  ‘Buying  Power’  for  Cost 

• Cannot  Drive  Designs 

• System  ‘Edge’  Devices  Interface  to  Custom  Mil  Interfaces 

• Several  Different  Form  Factors  (PCI,  PMC,  VME,  cPCI,  etc) 

• IEEE  1588  Tech  Insertion  Presents  a Change  to  the  System 
Infrastructure,  Rather  Than  I Component.  Questions  Raised 
Include: 

• What  are  the  System  Performance  Impacts? 

• Does  the  New  Technology  Increase  System  Cost 
Significantly? 

• Does  It  Impact  Applications? 

• What  Does  It  Take  to  Integrate  and  Test? 

1 6 September  2004 


Critical  System  Design  Analysis 
Test  Impacts 


Progeny  Systems 

' tnginecnng  yutions  that  last  Gcmraticns 


Many  Systems  Impacted  by  Infrastructure  Change  Are  ‘Ships 
Safety/Self  Protect’ . 

Example:  Forward  Look  Submarine  Sonar  System  Used  to 
Come  to  Surface 

• New  Technology  Is  Scrutinized  for  Impacts  to  These 
Systems. 

• Failure  Modes  and  Effects  Analysis  Is  Performed  on  Any 
Potential  Infrastructure  Candidate 

• Fail-over  Mechanisms  Need  to  Be  Supported  (Not 
Necessarily  As  Part  of  the  Standard),  and  Minimize  Impacts 
to  System  Architecture 

• Infrastructure  Changes  Generate  More  Complieated  Test, 
Retest  Scenarios. 

16  September  2004 


Progeny  Systems 

Issues  Raised  by  the  Customer:  ' {ii|inetrifig  kdiitions  That  Lart  Ctwratiens 


The  Ability  to  Achieve  10ns  (or  Lower)  Is  Not  Beyond  the 
Capabilities  of  1588,  but  Will  All/Some/Enough  COTs 
Devices  Be  Capable  of  Achieving  It? 

• Will  COTs  NICs  and  Switches  Replace  Current  Baseline 
Devices  Without  Infrastructure  Impact? 

• How  Will  Fail-over  Work? 

• What  Is  the  Failover  Time,  in  a Ships  Safety  Scenario, 
Provided  the  Data  Is  Still  Processed  in  a Degraded  Mode 
(Partial  Array  Processing)? 

• Will  Cots  Cards  Provide  a Clock  to  Source  the  Digitizers? 

• How  Will  Performance  Be  Affected  By  Information 
Assurance  Requirements? 

• How  Does  1588  Deal  with  IPV6? 

16  September  2004 


Progeny  Systems 

To  Universal  Data  Synchronization  ' EniragSaiyw  That  Last  totifflii 
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Progeny  Systems 

Data  Synchronization  ' EnpefragSoiBtioftite  last  taw 

Data  Sampling  Synchronization  Is  the  Underlying  Requirement: 

• Several  Processing  Units  Are  Needed  to  Sample  Data 
Coming  Into  an  Array.  They  Must  Sample  the  Data 
Synchronously  - the  Sample  Clock  Edges  Must  Be 
Synchronous  to  Within  10ns. 

• At  a Higher  Layer  the  Data  Buffers  Must  Have  Identical 
Timestamps  So  That  They  Can  Be  Processed  Together. 

• At  a Higher  Layer  Still,  the  Processed  Data  Needs  to  Be 
Timestamped  to  Correlate  to  Data  From  Other  Arrays 

These  3 Timestamp  Requirements  Have  Been  Implemented  in 
Various  Ways  in  the  Past,  Typically  As  Separate  Solutions. 

• They  Are  Not  Always  in  Sync 

• They  Use  Different  Standards 

• They  Use  Proprietary  or  Obscure  Standards 

16  September  2004 


Mechanisms  for  the  Insertion  of  IEEE  1588 

• Some  (But  Not  All)  Agencies  Support  a Planned  Approach 
to  Technology  Enhancement.  These  Use: 

• Research  Funding  Vehicles 

•Small  Business  Innovative  Research 
(SBIR)Program 

•Broad  Agency  Announcements 

• Technology  Insertion  for  existing  COTS  systems 

• ‘COTS  Technology  Refresh’  Cycle  Exist  to 
Introduce  System  Improvements 

• Need  Is  Identified  by  Performance  Requirements  of 
Baseline  Systems 

“Problem  Solving” 

1 6 September  2004 
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Progeny  Systems 

The  DoD  ASTO  Process  - Rapid  COTS  Insertion^  [ngineering  kiiutioiti  That  Last  Gewrariont 
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System  Technology  Insertion  Impacts 
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Rapid  COTS  Insertion  Process 


Progeny  Syitems 

\ fnitneeriflg  Motiofis  [(lat  last  Gentrattos 
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cT^  Progeny  Systems 

MIL-STD- 1553  Use  Case  \ 


Aircraft  Internal  Time-Division  Command/Response  Multiplex  Data  Bus 

• In  use  since  1973 

• Widely  applied. 

• ‘B’  version  created  to  specify  the  electrical  interfaces  explicitly  so  that 
compatibility  between  designs  by  different  manufacturers  could  be 
electrically  interchangeable. 

• The  Department  of  Defense  chose  multiplexing  because  of  the  following 
advantages: 

• W eight  reduction 

• Simplicity 

• Standardization 

• Flexibility 

• Can  utilize  more  than  one  data  bus  on  a vehicle. 

• Isolate  a Stores  bus  from  a Communications  bus 

• construct  a bus  system  capable  of  interconnecting 
single  bus  could  accommodate 
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Progeny  1553  to  Fibre  Channel  Bridge 


<\Z>  Progeny  Systems 

Bus  Architectures  \ &ipeeringWi3tisfi!ThatLastfeftfrati{fns 


Dual  1553  Bus  Architecture 
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Interfacing  1553  to  an  IEEE  1588  Network 


Progeny  Systemi 

A Enjtneering  Wlatiwis  That  Last  Gewration} 


A new  requirement  is  established  to  time  synchronize  the 


Progeny  Systems 

Interfacing  1553  to  an  IEEE  1588  Network  A EngragSoiBtim!  that  Last  tatm 


Initial  Analysis 

• The  1588-enabled  Network  Provides  the  Source  of 
Time 

• A 1 553  to  Ethernet  Bridge  Must  Be  Designed  to 
Connect  the  Interfaces  Electrically,  and  to  Translate  the 
Data 

• As  a Separate  Sub-system,  Each  Legacy  Bus  Generated 
Independent  Time  Data 

• A Single  Node  on  the  Bus  Was  the  Time  Data  Source 

• Time  Data  Is  Separate  From  the  Clock  Used  in  the  1553 
Interface 
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Implications 


Progeny  Systems 


[ngineeriHg  Solyfiofts  That  lait  (kntrations 


• The  Legacy  1553  Busses  Need  to  Be  Able  to  Support  a New 
Node,  Both  in  Software  and  Hardware 

• The  Previously  Unconnected  Systems  Must  Be  Able  to  Co- 
exist on  Ethernet 

• The  Legacy  Busses  Use  an  Internal  Time  Source  That  May  Be 
Stand-alone,  or  based  on  External  Interfaces 

• The  new  bridge  can’t  serve  time  to  the  1553  devices 

• The  Impact; 

• Wiring  and  Software  Changes  May  Be  Required  for 
Legacy  Devices  to  Recognize  New  Node  - Costly 
Development  & Integration,  Then  Significant  Testing  for 
the  Mil  System 

16  September  2004 


Options 


1 ) Revise  or  replace  the  components  in  the  system  that 
serve  time  to  act  as  timing  slaves  instead  using  existing 
protocol 
Pros: 

Impact  to  the  1553  system  may  be  minimal  - a 
single  node  might  be  the  only  device  affected 
1553  to  Ethernet  Bridge  would  be  a simple  end- 
device  for  PTP 
Cons: 

The  1553  clock  requirements  may  exceed  the  1588 
system  performance 
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Progeny  Systems 

Options  \ bilineeringtoriofts  That  last  (KMrations 


2)  Implement  1588  on  the  mil  1553  bus,  replacing  all  time 
services  with  PTP. 

• The  1553  to  Ethernet  bridge  would  become  a PTP 
Bridge 

• Pros: 

• If  the  1553  clock  requirements  exceed  the  rest  of 
the  network,  the  1553  clock  can  become  the  Grand 
Master  Clock 

• Cons; 

• The  development  and  integration  effort  may  be 
significant 


1 6 September  2004 


Conclusions 


Progeny  Systems 

\ Engineering  islytssfislhat  last  &{ftfratKfns 


• The  Impact  of  a Implementing  a Different  Time  Standard  or  Protocol  on  a 
Legacy  Mil  System  Can  Be  Dramatic  and  Costly 

• The  Introduction  of  a COTS  Baseline  in  Mil  Hardware  Systems  Provides  a 
Significant  Enabler  to  New  Technologies  Such  As  IEEE  1588 

• Even  When  Such  an  Architecture  Exists,  System  Analysis  and  Planning  Is 
Still  Required. 

• Some  Agencies  Recognize  This  and  Have  Built  Tech  Refresh  Processes 


1 6 September  2004 


Use  Case  - driven  ‘Wish  List  ’ Progeny  Systems 

for  IEEE  1588  Devices  ^ tnpecnngyutiOfisrharUitGfmratimi 


• Ins  Synch  Performance  (or  Better)  to  Meet  Requirements 
Across  a Variety  of  Applications 

• Programmable  Logic  Cores  and  Chipsets 

•Allow  Us  to  Make  a Card  Like  the  COTS  Cards 
•Ideal  to  Be  a FPGA  Core  for  the  10-20ns  Performance 
Area 

• Capability  to  Fail  Over  From  1 Master  to  Another  Without 
Significant  Loss  of  Data 

• COTS  Network  Devices  That  Are  Plug-in  Replacements  to 
Current  Devices 

• Interface  Signal  Cards  for  ‘Edge’  Requirements  - for 
Digitizers  and  for  Incoming  Time  Reference 

16  September  2004 


Aotoniatk  Test  Systems  iisiiig  LAN-based 
Synthetic  Iiistriiiiients  and  the  role  of  IEt£-l5S8 


John  Stnitioii 

Aglleiit  Techrioiogks.  iec\ 

Syiitiietic  Inslrnnients  Marketiiig/Plaiiiiiiig  Manager 


Agilent  Technologies 


Where  test  systems  got  started 

'Manual  control  of  test  instruments  and  data  recording  ' 

^ Operator  cllffereriees  (tniiiiiiig.  settings,  data  input  errors,  etc.) 

•Automated  measurements 

^ No  Standards  for  control 

^ No  Standards  for  tiiiiiiig  aocl  triggering  (Event  triggering) 

• BCD  (Binary  Coded  Decimal),  HPIB  (Hewlett  Packard 
Interface  Bus),  RS-232,  Etc. 

• Each  instrument  manufacturer  had  their  own  way  of 
programming  their  instrument 

• 10  MHz  synchronization  standard  (frequency  domain 
instruments) 

a^’>:ares 


•Benefits  of  software  control 

• RepeatabiliW  - The  instrument  is  set  up  in  the  same  condition 
every  time. 

• Accuracy  - The  resulting  data  is  stored/printed  without 
transcribing  errors. 

• Speed  - Higher  throughput  testing  due  to  minimal  operator 
intervention 


s«£>:.;s«r4!nu>rd: 


Sianiiards  sre  needled  tcir benefits 
oT  eeterriedor;  M>  siicceec! 

•Communication  interface  - GPIB  has  been  the  standard  for  25+ 


years. 


•Software  interface  - Standard  Commands  for  Programmable 
Instruments  (SCPI),  VXI  plug-and-play  have  been  around  for  15+ 
years 

ceiiipyter  slaiicterd  Driven  be  coiTimerciai  rieecls 

vNo  Operiitliig  System  (OS)  staiidarcl  - Driven  by  computer 
ii'iarriifactiirers  or  ciistiirii  OS 


cnidklencc 


Toclay^s  (}peit-stmHf{ird  ckmci^  fcir  syiitlietic  iiistruriieRts 


' ^hc^i:  ciu'ice-  ;h'c  based  Uk;  ^■?;;eknl;3ne  (d'u  vovnincrciai  conipuier  arcidleciure  standard 

sexi  VME  , whar:  pQ|> 

PCI  C-PCI  -WA 


Considvratiofis  of  Card  cage  niodnlarl?) 


i■?t:d?K■riffo  In  Ctnnrnon  componcfslv-Potcprirdly  Increase  in  relialsiliiy 

Pisn  er  Sisppty  -•  li  specified  povvs.:?-  H no?  ideal  I'K.-  in  DC  e«n%  erslon  inay  be  required.  A 
complete  a??alysh  of  tbe  curvunt  and  fotare  needs  irnis?  be  assessed  for  optJrattm  seieelioti 
stoo  ittueli  power  eqoab  nnder  inili nation). 


HIsh  Speed  Backplatte  - A vers  cost  t-ffeerivt  ase  of  coiapider  industry  standards  to  drive 
down  developutein  costs  and  tiute.  High  speed  nigger  l>ns.  However,  tliese  Standank  ore 
iKither  ivacktvtu'ds  cotnparlbic  or  Siahle  iForwards  cornpaliltlei. 


Compnler  processing  and  display  - Can  take  ndvainlnge  of  Ike  conllnuing  dow  nward  cost 
of  PCs.  liowever,  tde  endn-dded  PC’  s are  osnally  inodll-generatlons  behind  current  of-the- 
s’livlf  PC  products  -Miil  5-IOX.  more  espiutsivc. 

Compact  Instrooumf  Design  — Purcitasc  only  w hat  Is  reepdred.  Add  modules  as  the  need 
changes.  Many  vendors  are  available  lor  liwv  frepoeriey  components,  liosvevers  not  all 
funsdlonalily  is  available  \n  all  formats  (especially  RF  & itvvave)  forcing  multiple  card 
cage  types  or  the  use  of  old  products. 

Agiletd  assures 
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DoD  clri¥es  cost  and  size  reduction 

First  atteifipt  at  sta  ri  cl  a rdiza  lion  | Goals) 

•Smaller  form  factor  - Instruments  on  a card 

•Less  cost  - Elimination  of  front  panel,  computer,  common  power 
supply  and  display 

•Higher  Reliability  - Fewer  parts  equal  fewer  failures 

•Long  support  life  - Defense  test  systems  need  to  be  around  for  20+ 
years. 

Results 

•VXI  - Based  on  Computer  VME  architecture  for  instruments 
•SCPI/VXI  PnP  - software  communications  standards 

Agilent  assures 
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Where  do  we  go  from  here? 


mt''imremep.t  corilldc-rsce 


The  Flcif)  wcmlcl  like  wifli  Syntlietlc  liistriinieiits  to  ticlcli'ess: 

( Current  Gcialsi 

1.  Size  reduction 

it  Rtilme  reQumlnni  (same  or  similar)  functional  blocks  (Digitizers,  down- 
converters,  microprocessors,  displays,  etc.) 

2.  Total  Cost  of  Ownership  reduction 

a.  Elimination  of  redundant  hardware/software  will  reduce  total  aec|alsitHHi 
COSL 

b.  Fewer  iiniqwe  line  ifem^  will  shrink  logistic  footprint  (spares,  support 
systems,  training,  interoperability,  etc.) 

c.  Cmmumi  eiociyle  defirritloe  should  promote  competition. 

d.  SimpUned  hardware  modules  will  support  backw  ards  and  forward 
compatibility  (Protocl.  the  TPS)  of  test  systems 

3.  Faster  fieklirig  of  new  test  systems 

.\0U-tn  assures 
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SliCMiIcI  tecimology  diive  riicidiile  partitioning? 

2^  perlbriiisiece  iiocl/or  a liie  Ibr  llie  same  |.ieri'oiiiiatt€e 


Digital 

D/A  and  /or 
A/D  Conversion 

Analog 

RF/|Liwave 

/mmwave 

»DSP  Speed 

*a|>ri>c€SSf>r 

speed 

* M emory  sse 
aed  speed 

‘Higher  sample 
rale  for  a glvett 
dyeaiiiie  rlege 

® Higher 

dyaai.iiie  range  . 
for  a giveo 
sam|jle  rate 

Hllglier 
perl0rraa.aee  ' 

‘i,o«  cr  ? esf 

* / is  hcin/.', 

-MO  h;  /)/  s 

inn! . r?)  tsvKin  Uhh 

grmsii  whief!  wiU  _ . 
s'ifprire  S’^  giuiis. 

‘ 4f.s  mimdleally 
ap-’roachfog 

tile 

HiMinnMhte 

fb'wi'iS 

*Ad , jmces  rr^ 
Si/.v  am!  eosi 
are  key 

- Mimihs 

-24-36  Months  . 

-24-16  \'tomh<' 

" 36'~h4  Months 
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F/ifcoriiet 

Corii:riiiini€atiorr^%  irilerfkce  ttiiiC  will  last 
Supports  M eonipiJler  operating  systems 
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What  is  a Synthetic  Instrument? 

Based  on  SI  working  group  definition 

• A collection  of  hardware  and  softw  are  modules  that  can  be  concatenated 
together  to  emulate  a standard  instrument. 


Signal  Input 
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w agagg 
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t I Arbitrary  Waveform  Generator 

Vector  Up-Converter 

Agilent  ijssi^res 
ssj  r r ctmilfk-Hce 


Signal  Generator  Software 


Wtiat  is  a Synthetic  iristTunient  niednle? 


•An  EiciuentG:  building  block  of  a larger  measurement  system. 

• SI  modules  used  in  reconfigurable  applications 

• Simpler  the  building  block,  the  easier  to  upgrade 

• Standard  interfaces 

•Application  software  is  exsemai  to  the  SI  module 

•Characterization  softw'are  - characterize  the  measurement  path  to  provide  metrology 
grade  performance. 


.Vgfkiiic  a.ssares 
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Svnthetic  Instrument  Module  Ptivsica 
Dclinitioii  of  LAN  Based,  Module: 


E/.4  Standards 


Power 


,4giteu1  assures 
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5.  USB  On-The-Go  2.0  capable  of 
full  speed  communication  (host  and 
device) 

6.  Host  to  PCI  bridge 

7.  Internal  power  supply 


LXI : LAN  extensions  for  Instrumentation 


liidiisfrT  sfanciarcl:  LAN  Si  AC 

• Fast,  cheap,  ubiquitous. 

• No  expensive  cards,  cables  or  mainframes 

• LAN  in  forward  compatible 

• 1EEE1588  Timing  and  synchronization 
Standard 

• Industry  Consortium:  Open  Standard 


. « w » 
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Agilent  Synthetic  Instruments 


...  LTipact,  stanciarcl  sizes- 

• Typically  'A  the  size  of  rack  and  stack 

• ‘A  rack  (or  full),  !U,  2U,  4U  high 

• Depths:  13  'Z,  16  ‘A,  25  inches 


Power  Meter 


• No  expensive  card-cage  or  slot  0 computer  Power 

• Rack  & Stack  performance  and  measurement  Supply 

science  .r 

• Easy  to  build  product  environment  - m J 


measurcmcni  confidence 


LXl  Syiitiietk  Ifislraiiieiits  vs.  TraditifiiMil  Instrumeiiis 

Re-Con  fig  am  Me,  Re-Csabie.  Less  Reek  Spoce! 


z < ^ 

« ^ f a 

:i 

s;-  -'-^1 

X V J 

Simple  cable  design  for  high  channel  count  data 
acquisition  -LAN  vs.  Bundle  of  matched  cables 

Potential  elimination  of  distribution  amplifiers 

-May  require  better  timing  resolution  (~1  nanosecond)) 

High  throughput  measurements  using  time  bombs 

-parallel  vs.  sequential 

-removal  of  software  timing  wait-states 

Lower  cost  of  ownership 

- Test  and  measurements  assets  based  on  industry  standards 

\0\tni  asssii  es 
m ca su r c 5 s = e in  coo  11  dc»c t 


Agilerii  moves  industry- s best  technology  into 
Synthetic  Instronieiifs* 

Questions? 
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IEEE  1588  in  Telecommunications  Applications 


Dave  Tonks 
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Telecom  networks  have  many  areas  where  a common  time  base  is 
needed.  IEEE  1588  could  be  very  useful,  but  the  following  issues  are 
a barrier  to  its  adoption  : 

^ Telecom  paths  not  jitter-free  and  boundary  clocks  not  available 
PTP  messages  too  bandwidth-hungry  for  some  applications 
^ No  redundancy 
^ Time-To-Live  = 1 
Authentication? 


This  presentation  uses  a couple  of  example  applications  to  highlight 
these  issues  and  either  points  to  suggestions  made  by  the  working 
parties  or  suggests  new  solutions. 
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Example  1:  IEEE  1588  supporting  Circuit 


A network  clock  is  used  globally  for  synchronous  services 

Telco  Packet  Network 


Problem:  Adaptive-clocking  is  slow  to  lock  and  slow  to  follov^  drifts, 

and  is  also  vulnerable  to  packet  errors  and  Jitter, 

Fix;  Use  PTP  to  get  network  clock  in  each  customer  premises  from 

which  service  clock  can  be  generated. 
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The  delay  jitter  issue: 


Delay  jitter;  Lack  of  boundary  clocks  means  inter-packet  interval  changes  from 
regular  to  highly  irregular 

m I— ii— I [—1 1— 1 □_ 


Goa;:  OC  output  should  be  accurate  and  stable 

ProDlem;  random  delays  spoil  regularity  of  timing  packets 
Fix;  use  strong  filtering  in  OC  with  stable  local  oscillator 


Jitter 

10  8k  40k  *''■‘“‘1 

(Hz) 
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The  bandwidth  consumption  issue: 

MS 


Overcoming  delay  jitter  requires  higher  rate  of  PTP  messages  which,  on  low-speed 
telecom  links,  consumes  too  much  bandwidth  and  in  any  case  is  too  expensive  when 
charged  per-bit 


p^p 


r-i r-|  rn ... r- ir- 1 n 


PTP 

OC 


Goal: 

Problem: 

Fix; 


SsWptp  « EsWdata 

long  PTP  messages,  sent  at  higher  rate,  consume  too 

much  bandwidth 


reduce  message  size 


m 

rj 
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Semtech’s  proposal  for  short  messages 


versionPTP 

2 

versionNetwork 

2 

Subdomain  name 

16 

messageType 

1 

Information  about  source 

11 

Control 

1 

Flags 

2 

reserved 

4 

originTimestamp 

8 

epochNumber 

2 

currentUTCoffset 

2 

Information  about  Grandmaster 

20 

syncinterval 

1 

Information  about  local  clock 

6 

Information  about  parent 

9 

estimatedMasterVariance 

2 

estimatedMasterDrift 

4 

utcReasonable 

1 

versionPTP 

2 

versionNetwork 

2 

control 

1 

subdomainNumber 

1 

flags 

1 

shortSequenceiD 

1 

originTimestamp 

8 

syncinterval 

1 

Proposed  short  Sync  Message  (17  bytes) 

Mod  to  normal  Sync  Message: 

16-byte  subdomainName  mapped  to 
1-bvte  subdomainNumber 


Result: 


PTP 
Data  / 

p m D 0 n n onn  n d 


Present  format  of  Sync  Message  (94  bytes) 
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The  redundancy  issue: 


Telecom  clock  must  always  be  available,  even  during  component  or  network  failure. 


Goal;  High-availability  through  no  single  point  of  failure 
Fix;  add  redundancy  support 

rj 
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The  multicasting  issue:  ' " ^ 

Multicasting  is  used  but  is  limited  to  one  sub-net,  with  the  premise  that  a boundary  clock 
controls  the  next  sub-net;  but  ( 1 ) telecom  networks  will  not  have  boundary  clocks,  so 
FTP  is  blocked,  and  (2)  slaves  will  be  swamped  by  higher  rates  of  delay  messages... 


r-  FTP 
OC  #n 


To  get  through!  To  avoid  swamping  slaves. 
Avoid  high  rates  of  multicast  messages,  maybe 
use-  unicast  for  short  delay  messages. 
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Example  2:  IEEE  1588  could  support  OSS 


Operations  Support  Systems  would  benefit  from  a network-wide  time 
base; 

■ Billing  activities  in  high-speed  all-packet  network  will  develop  beyond 
today’s  distance/duration/tariff  or  subscription  models: 

• For  each  packet,  take  note  of  type-of-service  (eg,  video,  on-line  gaming), 

• Take  note  of  sum  of  packet-durations/service 
' Charge  customer;  pay  content  providers 

* SLA-compliance  checking: 

• Report  detected  anomalies,  failures 

' Cross-check  with  similar  report  from  CPE  (needs  accurate  timestamping  in  CO  and  CPE) 

• Schedule  maintenance 
' Credit  customer 


Semtech  confidential  - unauthorized  copying  prohibited  SEI\/ITE^H-| 


IEEE  1588  supporting  OSS: 


GPS  satellite 


Customer 

Premises 


i-P 


Central  Offic 


GPS  satellite 


Custoiji 

Premil 


Centre 
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Summary 

If  the  issues  which  have  been  highlighted  can  be  solved,  PTP  offers  a simple 
way  to  get  a common  time  base  across  a network  with  much  better  accuracy 
than  present-day  alternatives. 

Issue:  Excessive  accumulation  of  delay  jitter  caused  by  lack  of  boundary  clocks: 

Solved  by  long-term  filtering,  but  needs  faster  message-rate  if  local  oscillator  clock 
cost  is  to  be  kept  down 

Issue:  Bandwidth  consumption  makes  PTP  expensive: 

• Higher  message  rate  consumes  more  link  bandwidth,  strangling  low-speed  links 
and  costing  excessive  amounts  on  higher-speed  links. 

Fixed  if  shorter  messages  are  used. 

O'  Issue:  Reliability  concerns  avoided  if  redundancy  support  added 
' Issue:  Routing/bandwidth  compromise  (multicast  issue): 

» Need  to  define  a way  round 
^ Issue:  Authentication  of  time  source: 

* Need  to  define  a way  round,  if  not  guaranteed  by  network  topology. 
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Telecom  Update  to  IEEE1588  Workshop 

Sept  29  2004 

Glenn  Algie,  Senior  Advisor 
Broadband  Access  Solutions 
Nortel  Networks 

8jqie{d)iiortetiietworks.€Ofn,  613  765  3435 
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Recap  of  key  messages  into  Telecom 

Summary  of  1EEE1588  past  year  events  in  Telecom  - Public  Networks 
Summary  of  Telecom  IEEE1588  key  needs  - Norte!  view 
IEEE1588  “Ethernet  MAC  distinguishable”  Items  for  PAR 
Telecom  Next  Steps 

Q&A 

IEEE158«  workshop  Sept  77 -7Z  2004, 

Glenn  Ai^ie 
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Solution  Proposed 

Nortel  Networks  proposes  that  1EEE1588  be  adapted  for  this  need.  Positioned  as  a precision 
timing  service  over  Metro  Ethernet  demarcations  into  Wireless,  Broadband,  or  Enterprise 
Slight  enhancements  to  IEEE1588  standard  are  proposed  for  these  Metro  Ethernet  services 
1588  timing  payloads  are  extensible  to  any  frame/cell  packet  transport 
Does  not  replace  NTP,  can  interwork  with  it 


nGrtel 

NETWORKS 

CAP:  Telecom  Drive  for  IEEE1588 


roblem  Statement 

Transition  is  now  occurring  from  circuit  to  packet  in  the  metro 
Ethernet  edges  are  replacing  traditional  E1/T1  circuit  demarcation 
Precision  timing  typically  reduces  cost  of  time  sensitive  applications 

Timing  sensitive  endpoints  being  impacted  are  Cellular, Broadband  DLC,  and  SME  Enterprise 


lEEElSaS  workshop  Sept  27-28  2004. 
Gienn  Atgie 
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"RECAP:  IVletro  Ethernet  Timing  Packet 

Dimensions 

Precision  Timing  Service  components 

Timing  Sourcing  edge  point(s) 

Timing  Recovery/Adaptation  edge  points 
Timing  Sensitive  Service  edge  points 


Management  and  ownership  options 

Enterprise  managed  service/device 
Metro  Provider  managed  service/device 
Hosted  Service  provider  service/device 


Variety  of  Metro  Ethernet  Network  Impairments 

Metro  core  vs.  Metro  collector  & edge.  Ring  vs.  Mesh  vs.  Star  topologies 

Ethernet  over  802.17  (RPR)  vs.  Ethernet  over  Sonet  vs.  Ethernet  over  WDM  vs.  others 

Technology  & Architecture  combos  have  performance  impact  on  1EEE1588  PTP  flows 


l£EEtS88  worktop  Sftpl  27-28  2004, 
Gtenn  AJgte 


RECAP:  IEEE1588  on  Metro  Ethernet 
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Ref.  Architecture 


G Ethernet 

“njjr~^  Metro  Collectoj 


Ring/Mes 


\ Metro  Collector-'^. 
“ Ring/Mesh 


3G  Wireless  ** 

Cell  Site  > 
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Eth(  met  last  mile  drops 
EFt  802.3ah 


*;  _ Etiirnet 
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Industrial  I 
Enterprise  ^ 

! 

■^-0  Ethe|net 

^ UNI 

Broadband 
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Timing  network  impairments 

• 0 to  20  msec  latency 

• 0 to  3 msec  delay  variation 

• 0 to  1 % packet  loss 
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Device 

Ownership 

!EEE1588 

Servers 

Timing 

Adaptations 

Timing  Sensitive 
Services/Devices 

Metro 

Provider 

X,Y 

F,  G,  H,  K 

Enterprise 

User 

Z 

C.  E 

A,  B,  C,  D,  E 

Enterprise 
Branch  LAN 
& Circuits 


Telecom  - Public  Networks 
Summary  of  IEEE1588  relevant  events  (2) 
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IEEE1588:  Sept  2003  Telecom  proposal-  Nortel  Networks,  sub  second  rate 
& L2  multicast/Ethertype  needs 


ITU-T  SG15  Q13:  Nov.  2003  proposal  made  - Zarlink/Nortel,  Outcome:  work 
item  is  active,  Circuit  emulation  over  packet  use  case  focused 


NIST  T1X1  Sync  workshop:  Feb  2004,  a number  of  1EEE1588  proposals  and 
discussions,  Outcome:  No  push  back,  Raised  awareness  for  IEEE1588  into 
Telecom,  gained  some  Telecom  Timing  vendors  support  & visibility 

T1X1.3:  Actively  working  on  “Synchronization  of  Packet  Networks”  report 
(Nortel,  Zarlink  have  been  contributing  to  this  work). 


T1X1.3:  Mark  Jones  of  Sprint  held  2 public  conference  calls,  objective  to 
collect  Telecom  sync  initiatives,  minutes  for  each.  Mar  10  - May  20 


IEE.E1S88  WQrt(ftbop  Sftpt  77-28  2D04, 
GIftnn  Ai^te 


NGRTEL 

NETWORKS 

WiT?<{3i5t  DOUK&A&iSS. 


Telecom  - Public  Networks 
Summary  of  IEEE1588  relevant  events  (2) 


Continued 

802.3  Ethernet  First  Mile,  March  2004  Plenary, 

- Gibson  Guitar  sponsors  Plenary  entertainment  evening  - Guitar  \with  RJ45: 
proprietary  synchronous  music  MAC,, 

- informal  meet  held  Consumer  Electronic  vendor  teaming  around  Synchronous 
Ethernet  for  the  Residential  LAN.  Karl  W.  of  Siemens  presents  industrial  use  case, 
1588  timestamp  like  framing  at  lOOO’s.-'second  rate 

802.3,  July  2004  Plenary:  Successful  launch  for  “Residential  Ethernet”  study 
group.  Residential  Ethernet  = Synchronous  Ethernet 

MEF:  Aug  2004,  propose  as  option  in  “Ethernet  UNI”,  Telecom  sponsors 

IEEE1588:  Sept  2004  workshop  @ NIST,  include  sub  rate  and  L2  multicast  in 
1588  PAR 

802.3  Sept  Interim;  Residential  Ethernet  study  group  first  meet  Sept  29  -Oct  1 


tEEEISaS  wor>.shop  Sept  27-22  2004. 
Glenn  AJgie 


IEEE1558  PTP 


Feb 2003  Lab  Setup  & results 
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40  00  MI’.s  teie’fincfi 


1 Spectiurn  Anaky^i^ 


IEEEt583  PTP  Slave 

¥CXC' 


KfvefOel  FFGA 

PhV  kit 


(10  p^acKds  per  sscorid^ 
A-3itep«  15SS  prototype  (iffi  loan) 


lEEEISHe  wOfKsEop  Sept  27-28  2004, 
Glenn  AJyte 
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Sprint  Conf  Call  & iVlinutes:  May  20  2004 

Sprint:  Mark  Jones,  Chuck  Norman,  Jim  Black 
Nortel;  Glenn  Algie,  Michel  Ouellette,  Michael  Mayer,  Richard  Brand 
Semtech:  pdiamond@semtech.com;  skefly@semtech.com 
Zarlink:  silvana.rodrigues@zariink.com 

Symmetricom:  kshenoi@symmetricom.com;  Jolsen@symmetricom,com; 
€i2:a.mpettl@S¥m metrlcom .com ; dwinn@symmetricom.com 
Agilent:  John_eidson@agiient.com;; 

Biholar,  Ken; 

Telcordia;  Wertheimer,  Adam;  tbowmaster@telcordia.com 

Alcatel:  blii.powen@a!cateLcotTi; 

Key  item: 

Uncertainty  over  possible  overlap  between  scope  of  T1X1.3  TR  on  sync  in 
packet  networks  and  the  new  ITU-T  draft  Rec.  G.pactiming  - interest  in 
both  groups  to  work  together,  possibly  generate  another  liaison  at  July 
T1X1.3  meeting 

Action:  Follow  up  with  Mark  Jones  needed  on  progress 


JEEEISaS  workshop  Sept  27-25  2004, 
Glenn  Ajoie 


Company  Contact 

Nortel  Networks  rsantitgro@nortelnetworks.com 


ou€Tietl@riortelnetworks.com 

3Jciie@nortelnetworks.com 
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Agilent  Technologies 


Zarlink  Semiconductor 


Semtech  Corp 


Symmetricom  Inc. 


l£F.E1S8e  workshop  Sept  27 2004, 
Glenn  Aigie 
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!>OUK5>#iWi£5 

Summary  of  Telecom  IEEE1 588  key  needs  - Nortel  view 

As  optional  overlay,  define  a IEEE1 588-compact  ( 64  byte  total)  run 
time  compatible  message  format 


Remove  non-timing  related  material  from  Ethernet  payload  (IEEE  1588's  origins 
are  in  industrial  control  applications  \A/here  machine  OAM  information  is  included 
in  the  current  protocol  payload  definition.  This  OAM  info  is  not  needed  for 
telecom.)  The  objective  of  this  change  is  to  get  the  payload  down  to  64  bytes. 


• Work  the  July  2004  Semtech  submission  to  1 588  task  group 


2.  Get  L2  Multicast  OUl  and/or  Ethertype  assigned  - IEEE  SEC 

3.  Increase  rate  at  which  timing  packets  are  sent 

Add  backward  compatible  “sub  interval”  field  to  identify  if  “interval”  is  seconds  or 
milliseconds 


• 10  PPS  has  shown  good  results  in  lab  tests 

• 100  PPS  is  fastest  rate  expected 

• xOOO  PPS  could  fit  a 802.3  Residential  Ethernet  Study  Group  proposal 

4.  Allow  Vlan  tagging, 

NOTE:  Ethernet  standards  are  active  in  “stacked”  Vian  (“Q  inQ)  and  “stacked”  Ethernet 
(MAC  in  MAC). 
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Ethernet  MAC  distingyishable”  items 
for  fEEE1588  PAR 


H I"  fi’  (tn 


U Ml* 

ill’ li  ,ir 

81’  tHUr  iljft*'  tlHN’i’t  U'\ 

lAA. 

I.Z 

tthrmns  2 

} ’•IVC  <■  >3*81(1,11  -f 

I’SV'ja .. 

* t 

Propose:  i 

Reserve 
“non-link  | 
constrained”  | 
fWulticast  ID  J 

'■'ny/  / 

Consider;  |. 
Impacts  of  2 
1588  new 
Ethertype  f 


Objective;  allow  simpler  Ethernet  switch/bridges  (Multicast  aware  and  non 
multicast  aware)  ability  to  uniquely  identify,  steer,  replicate  and  prune  the 
IEEE1588  precision  timing  flow  based  strictly  on  Ethernet  MAC  parameters. 

To  date  we  are  limited  a VLAN  mapping  approach,  this  is  not  sufficient  for  a 
MEF  proposed  mandate  for  IEEE1588  on  “Ethernet  UNI” 

lEEEISee  workshop  Sept  27-28  2004. 

Glenn  Aigie 
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WiTMjSV!-?  &00«fifAUi65 

Ethernet  MAC  addressing  8t  control 


Logical  Link  Control 
LLC 


Medium  Access  Control 
MAC 


Link  Aggregation 
Control 


Ethernet 

MAC  Control  Laver 


24  bits  OUI 


24  bits  vendor-specified 


(vendor  block  code) 


(unique  identifier) 


0 = Globally  administered  (globally  unique) 

1 = Locally  administered  (locally  unique) 

0 = Physical  address  (unicast) 

1 = Logical  address  (multicast) 


Do  Nothing: 

IP  multicast  DA  get 
smapped  to  vendor  id 
+ portion  of  IP 
multicast  at 
MAC  C -- 


Teieconn  » Key  Next  Steps 


NGRTEL 
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Must  have  a short  term,  Jan  05,  public  deliverable  from  the  IEEE1588  PAR  to 
establish  the  proposed  iEEE1588  mandate  over  Metro  Ethernet  Forum  “Ethernet 
UNI”. 

- Secure  a IEEE  OUI  “non-link  constrained”  multicast  id 

- Secure  a Ethertype,  if  needed 

- Issue  1588  voter  approved  paper  similar  to  the  IEEE1588  over  IP  appendix 

- Go  back  to  MEF  for  vote  to  “mandate  iEEE1588  use  across  the  ‘Ethernet  UNI’, 
IF  the  User  end  point  service/application/device  requires  a precision  time 
reference”. 

Must  increase  Telecom  awareness  and  Telecom  vendor  alignment  towards 
IEEE1588. 

- “Ethernet  UNI”  rolls  in  2005  into  Telecom  - Public  Networks 

- Watch  for  timing  sensitive  service  roadblocks,  ie  Wireless,  Enterprise  and 
Broadband  end  point  services/appiications/devices  transitioning  connectivity 
from  Metro  Sonet/SDH/Circuit  to  Metro  Ethernet 

Must  seek  out  at  least  one,  prefer  2,  Metro  Provider  volunteer{s)  to  do  a 6-12 
month“Soak”  on  a time  distribution  solution. 

- Eg.  Bell  Canada,  SBC,  Bell  South,  Verizon. ...France  Telecom. ...NTT  Japan...  etc 

- Leverage  Plug  fest  like  1588  test  benches  & protocol  analyzer 

- Accessible  by  the  vendors  to  pull  regular  stats 

- Issue  public  report  to  1588  and  to  selected  Telecom  forum 

IEEE1SS8  workshop  Sept  27-28  2004, 

Gtenn  Afgie 


197 


FINAL  PARTICIPANTS  LIST 


Mr.  Glenn  Algie 

Nortel  Networks 

3500  Carling  Ave 

Ottawa,  K2H  8E9 

CANADA 

613-765-3425 

algie@nortelnetworks.com 

Anthony  Ander 

Agilent  Technologies 
Penang,  10460 
MALAYSIA 
604-680-7231 
604-645-6604 

Galina  Antonova 

8525  Baxter  PL,  Ste  100 

Burnaby,  BC  V5A  4V7 

CANADA 

604-421-8629 

604-421-8707 

galina.antonova@ge.com 

Dr.  Douglas  Arnold 

Symmetricom 
3750  Westwind  Blvd 
Santa  Rosa,  CA  95403 
USA 

707-636-1929,  Fax:  707-527-6640 
damold@symmetricom.com 

A.  Bailer 

Siemens  AG 
Gleiwitzer  Str  555 
GERMANY 

Mr.  Nick  Barendt 

VXI  Technology,  Inc. 

5425  Warner  Rd,  Ste  13 
Valley  View,  OH  44125 
USA 

216-447-4059,  fax:  216-447-8951 
nbarcndt@vxitech.com 

.Mr.  Dominic  Bechaz 

Zurich  Univ.  of  Applied  Sciences 
Technikumstrasse  9 
Postfach  805,  Winterthur 
CH-8401 

SWITZERLAND 
-41  52  2677148 
dominie. bechaz@zhwin. eh 


Mr.  Gary  Bernhardt 

VXI  Technology  Inc. 

5425  Warner  Rd,  Ste  13 
Valley  View,  OH  44125 
USA 

216-233-3799 

garyb@vxitech.com 

Mr.  Antonins  Boiler 

Siemens  AG,  A&D  PT  2 M 

P.O.  Box  4848 

Nuremberg,  90327 

GERMANY 

+49  (911)  895-5071 

+49(911)  895-4845 

antonius.boller@siemens.com 

Mr.  Tan  Boon  Keat 

Agilent  Technologies 
Bayan  Lepas,  1 1900 
MALAYSIA 
604-680-5744 

gilbert-bk_tan@agilent.com 

Bruce  Boyes 

Systronix  Inc 

555  S 300  East 

Salt  Lake  City,  UT  84111 

USA 

801-809-2658 

801-534-1019 

bboyes@systronix.com 

Mr.  Jim  Brad 

USNO 

3450  Mass  Ave.,  NW 
Washington,  DC  20392 
USA 

202-762-1452 

brad.jim@usno.navy.mil 

Seela  Raj  D.  Rajaiah 

Agilent  Technologies 
Bayan  Lepsa  FIZ 
Bayan  Lepas  1 1 900 
MALAYSIA 
604-680-8741 
seela-raj_raj@agilent.com 


Dr.  Patrick  Diamond 

Semtech  Corp 
200  Flynn  Rd 
Camarillo,  CA  93012 
USA 

805-469-3530 

pdiamond@semtech.com 

Dr.  John  Eidson 

Agilent  Technologies 

3500  Deer  Creek  Rd,  MS  4-M-A 

Palo  Alto,  CA  94303 

USA 

650-485-4263 

650-485-3894 

john_eidson@agilent.com 


Mr.  Michael  Gerstenberger 

KUKA  Development  Labs 
22500  Key  Dr 

Clinton  Township,  MI  48360 
USA 

248-844-0561 

248-844-0505 

MichaelGerstenberger@KukaDevLabs.com 

Mr.  James  Gilsinn 

NIST 

100  Bureau  Dr,  MS  8230 
Gaithersburg,  MD  20899-8230 
USA 

301-975-3865 

301-990-9688 


Mr.  Mark  Elliot 

Symmetricom 
3750  Westwind  Blvd 
Santa  Rosa,  CA  95403 
USA 

707-636-1932 

707-527-6640 

melliot@symmetricom.com 


Mr.  Tarrance  Graham 

Weed  Instrument  Company 
707  Jeffrey  Way 
Round  Rock,  TX  78664 
USA 

512-434-2817 

512-434-2851 

tgraham@weedinstrument.com 


Tom  W.  Farley 

Symmetricom 
100  Michael  Angelo  Way 
Bldg  E,  Ste  900 
Austin,  TX  78728-1257 
USA 

512-721-4058 
512-  721-4603 
tfarley@symmetricom.com 

Mr.  John  Fischer 

Spectracom  Corp. 

95  Methodist  Hill  Dr.,  Ste  500 
Rochester,  NY  14623 
USA 

585-321-5800  ext.  112 
jfischer@spectracomcorp.com 

Mr.  Douglas  Fowley 

GE  Energy 

1501  Roanoke  Blvd,  Rm  281 

Salem,  VA  24153 

USA 

540-387-8598 

540-387-8651 

Douglas.Fowley@ge.com 


Dr.  John  Guilford 

Agilent  Technologies 
1615  75th  St  SW 
Everett,  WA  98203 
USA 

425-356-6057 

Ken  Harris 

Rockwell  Automation 
1 Allen-Bradley  Dr 
Mayfield  Heights,  OH  44124 
USA 

440-646-3621 

krharris@ra.rockwell.com 

Mr.  Oyvind  Holmeide 

OnTime  Networks  AS 

Glads  vei  20 

Oslo,  489 

NORWAY 

+4722090304 

+4722090310 

oeyvind@ontimenet.com 


Hassan  Hussain 

Agilent  Technologies 
Bayan  Lepas  FTZ 
Penang.  11900 
MALAYSIA 
^604-6805523 

hassan_hussain@agilent.com 

Dominic  ladonis 

Hirschmann 
20440  Centuw  Bh  d 
Germantown,  MD  20874 
USA 

240-686-2329 

diadonisi@hirschmann-usa.com 

Mr.  Nikolaus  Kero 

Oregano  Systems  Ltd. 

Phorusgasse  8 

Vienna,  A- 1040 

AUSTRIA 

-r43  676  312  69  64 

-43  676  84  31  04-888 

keroe@oregano.at 

Mr.  Robert  Kroboth 

Agilent  Technologies 
1900  Garden  of  the  Gods  Rd 
Colorado  Springs,  CO  80919 
USA 

719-531-4415 

bob_kroboth@agilent.com 

Mr.  Kang  Lee 

NIST 

100  Bureau  Dr.,  Stop  8220 
Gaithersburg,  MD  20899-8220 
USA 

301-975-6604 

301-990-3851 

kang.lee@nist.gov 

Ms.  Ya-Shian  Li 

NIST 

100  Bureau  Dr 
Bldg.  225,  Room  A47 
Gaithersburg,  MD  20899 
USA 

301-975-5319 

301-975-8069 

ya-shian.li@nist.gov 


Mr.  Mondy  Lim 

Semtech 

10  Wimbledon  Way 
Ottawa  K2K3J2 
CANADA 
613-862-1188 
mlim@semtech.com 

Mr.  Hung  Mach 

Boeing 

P.O.  Box  3707 
MS  14-ME 
Seattle,  WA  98124 
USA 

206-655-9926 

206-655-7724 

hung.k.mach@boeing.com 

Mr.  John  Mackay 

Progeny  Systems 
9500  Innovation  Dr 
Manassas,  VA  20110 
USA 

703-368-6107  ext.  144 

703-331-5651 

john.mackay@progeny.net 

Dan  Maxwell 

Tarallax  Wireless  Inc 
low  100  S,  Ste  600 
Salt  Lake  City,  UT  84101 
USA 

801-533-2727 

801-355-0289 

dmaxwell@tarallax.com 

Mr.  Matthew  McConnell 

VXI  Technology,  Inc 
5425  Warner  Rd,  Ste  13 
Valley  View,  OH  44125 
USA 

216-447-4059 

mattm@vxitech.com 

Mr.  Paul  Mecklenburg 

VXI  Technology,  Inc 
5425  Warner  Rd,  Ste  13 
Valley  View,  OH  44125 
USA 

216-447-4059 

216-447-4059 

paulm@vxitech.com 


Mr.  Dirk  Mohl 

Hirschmann  Electronics 
Stuttgarter  Strasse  45-51 
Neckartenzlingen,  72654 
GERMANY 

dmohl@nt.hirschmann.de 

Mr.  Anatoly  Moldovansky 

Rockwell  Automation 
1 Allen-Bradley  Dr 
Mayfield  Hts.,  OH  44124 
USA 

440-646-5369 

440-646-3076 

amoldovansky@ra.rockwell.com 

David  Moyer 

Semtech  Corp 
958  Spring  City  Rd 
Phoenixville,  PA  19460 
USA 

610-792-9395 

dmoyer@semtech.com 

Mr.  Paul  Myers 

Spectracom  Corp. 

95  Methodist  Hill  Dr.,  Ste  500 
Rochester,  NY  14623 
USA 

585-321-5800  ext.  158 
pmyers@spectracomcorp.com 

Dr.  Lee  Ng 

Agilent  Technologies  Inc. 

3500  Deer  Creek  Rd 
Palo  Alto,  CA  94304 
USA 

650-485-5726 

lee_ng@agilent.com 

Mr.  Sven  Nylund 

OnTime  Networks  AS 

Glads  vei  20 

Oslo,  489 

NORWAY 

+4722090308 

4722090310 

sven@ontimenet.com 


Ms.  Karen  O'Donoghue 

NSWCDD 
17320  Dahlgren  Rd 
Dahlgren,  VA  22448 
USA 

540-653-1567 

540-653-8673 

odonoghuekf@nswc.navy.mil 

Afshaneh  Pakdaman 

P.O.  Box  2202 

Santa  Clara  , CA  95055 

USA 

afshan@sfsu.edu 

Mr.  Rick  Pennavaria 

Weed  Instrument  Co 
P.O.  Box  300 
Round  Rock,  TX  78680 
USA 

512-434-2917 

Edward  Powers 

3450  Mass  Ave.,  NW 
Washington,  DC  20392 
USA 

202-762-1451 

202-762-1511 

powers.edward@usno.navy.mil 

Mrs.  Silvana  Rodrigues 

Zarlink  Semiconductor 
400  March  Rd 
Ottawa,  K2K  3H4 
CANADA 
613-270-7590 
613-592-1010 

silvana.rodrigues@zarlink.com 

Mr.  Michael  Rupert 

Zarlink  Semiconductor 
400  March  Rd 
Ottawa,  K2K  3H4 
CANADA 

613-592-0200  ext.  7347 
michael.rupert@zarlink.com 


Mr.  Paul  Rushton 

Semtech  Corp. 

Units  2 & 3 Park  Court 
Premier  Way 
Hampshire,  S051  9DN 
UNITED  KINGDOM 
44  01794527600 
prushton@semtech.eom 

Mr.  Stephan  Schuler 

SIEMENS  AG 
Brauckstr.  14 
Witten,  58449 
GERMANY 
-49  2302  667  2063 
-49  2302  667  3228 
schueler.stephan@siemens.com 

Mr.  Puneet  Sharma 

Intel  Corp 

5000  W Chandler  Blvd 
Chandler,  AZ  85226 
USA 

puneet.sharma@intel.com 

Dr.  Mark  Shepard 

GE  Energy 
1501  Roanoke  Blvd 
Salem,  VA  24153 
USA 

540-387-8710 

mark.e.shepard@ge.com 

Mr.  Paul  Skoog 

Symmctricom 
3750  Westwind  Blvd 
Santa  Rosa,  CA  95403 
USA 

707-636-1955 

pskoog@symmetricom.com 

Y uyin  Song 

NIST 

100  Bureau  Drive,  MS  8220 
Gaithersburg,  MD  20899 
USA 

301-975-6542 

yuyin.song@nist.gov 


Samuel  Stein 

Timing  Solutions  Corp 
4775  Walnut  St,  Ste  IB 
Boulder,  CO  80301 
USA 

303-939-8481 

303-443-5152 

lfischcr@timing.com 

John  Stratton 

Agilent  Technologies 

1400  Fountaingrove  Pkwy 

Bldg3LS-V 

Santa  Rosa,  CA  95403 

USA 

707-577-3838 

707-577-5834 

john_stratton@agilent.com 

Mr.  David  Tonks 

Semtech  Corp 
Units  2 & 3 Park  Ct 
Primier  Way 
Hampshire,  S05 1 9DN 
UNITED  KINGDOM 
+ 44  1974529600 
dtonks@semteeh.com 

Mr.  Murray  Tysinger 

Agilent  Technologies 

5301  Stevens  Creek  Blvd 

MS-51U-23 

Sants  Clara,CA  95051 

USA 

408-553-2640 

408-553-6591 

butch_tysinger@agilent.com 

Dr.  Bradley  Van  Eck 

Inti  SEMATECH 
2706  Montopolis  Dr 
Austin,  TX  78741 
USA 

512-356-3981 

512-356-7848 

brad.van.eck@ismi.sematech 


Mr.  Saso  Vlahu 

ST  Microelectronics 

1300  E Woodfield  Rd,  Ste  410 

Schaumburg,  IL  60173 

USA 

847-585-3017 

847-517-1943 

saso.vlahu@st.com 

Dr.  Aljosa  Vrancic 

National  Instruments 
1 1 500  N Mopac  Expwy 
Austin,  TX  78759 
USA 

512-683-8082 

aljosa.vrancic@ni.com 

Dr.  Karl  Weber 

Siemens 

Wuerzburger  Str.  121 
Fuerth,  90766 
GERMANY 
+49  171  230  7569 
karl.weber@siemens.com 

Mr.  Hans  Weibel 

Zurich  Univ  of  Applied  Sciences 

Technikumstrasse  9 

Postfach  805 

Winterthur,  CH-8401 

SWITZERLAND 

+41  52  2677552 

hans.weibel@zhwin.ch 


Dr.  Joseph  White 

U.S.  Naval  Research  Lab 
4555  Overlook  Ave  SW 
Code  8150 

Washington,  DC  20375 
USA 

202-767-5111 

202-767-4050 

Joe.white@nrl.navy.mil 

Mr.  Michael  Wilson 

Agilent 

14040  Pierce  Rd 
Saratoga,  CA  95070 
USA 

408-867-5526 

mikewilson30@comcast.net 

Steven  Wissler 

1322  Marie  Ave 
Ephrata,  PA  17522 
USA 

717-393-3831  ext.  140 
stevew@godfrey.com 

Mr.  Steven  Zuponcic 

Rockwell  Automation 
1 Allen-Bradely  Dr 
Mayfield  Hts.,  OH  44124 
USA 

440-646-5384 

440-646-4344 


‘r.  I 


A ‘ 


' ^ “f 

i®'  "'  ' “'  ‘ 

'•  " 

)J  l';>Tlt/r'^$fllt  y,,v,>n. 

i#^.*-.  ;;<r;,t  |*|>,,  '»^Hli'>'  Ot<\. 


'AT 


''>*"(''l^^'"^^.""':,  y;‘i  i 


. 4 ' 

• • ■"  ’ j * Uj  ' r ^ 

h .1  I'H  . 


■iili 


vt-M  v'i^, 

•//:.  .nlf*.'  J.^,! 


'X  ' ,>  i r|^^;i'.-y'Vj*^  ^'' 


nr  (I  ' r*  , ' /"r'fsi  % 

,.  ,•  ^ .r. 

" ■ . S'  ^''  ■:  S-^r' 

'f.  J- 

. :■,;  MdJ  ', , ^ ■ 

TmTH  !■.« 

ikiM-w  l'*»^  T <i  ' ’ 1 

WW-  '"  _ -" 

Mi,4i^5^'i:b^ik3  1 -‘'rt  iiii  I'^HMIff' 

m 


tTj^y;k4'‘: 


■»>?:>''''  'Jt'*-  '»{I^ 

■I'  r uyW':'''V:y!^ 

tX  t'  (/'’Ij.*'  ».!  -'■  jiii  ♦ ’ 


*•  '^v  ■ V^  ' ■ '''  ; ii'ti ’!«'W>^' •yr"''^ 

‘•^-  “■  ■ ‘ ' « Wf^:’ w:; 

' .Ti:^  ' “ rX';'’" 


I '.;  ■''■•.  if.!  .., 

^ ''  'h 


■'£, 


J?''  (r,i('!"  iriiillvl 


■T'rm'Tii 


'■/t 


i>  I 


.r-  ,,,: 


f t;i4-*  fV/  b :;,.  ■' » 


r.  ■' 


■^Vii 


"a 


V -Is® 

p*;7'ii 

T:.« 

■ >';»„.  .^lllii 

■,;l')  (,'V!,i).'*4 

■1.  J?.  -,  >1. 

™ ^ ..  J 

'll 

'"mm  * 

r9 

1)  .] 
3 j 

Im' 

w 

;j 

'i;-  ..  . 

'< 

■y®  y 

r ’■  ■ 1 ., 

■^  m . 

' ''■'  ^'*  '7j 


f' 


m wti'* 


